# Setting up the Network Configuration and Policies

## Channel Configuration

### Network configuration

- Consortium members decide the network setup:
1. Organizations
Members need to include the initial set of organizations that will be part of the network
2. Peer
Each organization will have Anchor peer
Peer identified on the network
4. Ordering Service
Administrator peer for the network
6. Channels
Channels setup
8. Client (Application)
Client setup
1. Policy

- Policies defined at multiple levels
- Organizations
- Ordering Service
- Channels

- Stored in Ledger as a transaction
- Consensus driven changes enforced by Policies
- Transparency
- Builds trust
- Built in audit for config changes
- Even Policies can change over a period of time
-
#### Config update transactions

- Config update Tx are submitted for making changes
1. Administrator send config update transaction
2. Through the same process as the normal transactions
3. Execute by the Configuration System ChainCode(CSCC)
4. If it has been validated will be delived by orderers in Config block
- Config Block
that has only one transaction that is the config update Tx
5. All of the peers received the config block the config update Tx and used the latest configuration contained in the transaction for all subsequent activities

#### Orderer System Channel

- Orderer system channel
- it is a special channel that gets created of the network initialization (Boostrap channel)
- All of the peers and orderers in network are aware of the orderer system channl by way of the genesis block
- Orderer and peers use the orderer system channel for initialization and that is the reason
- it is also referred to as the Bootstrap channel

- Created as part of initialization
- Network configuration holds in the orderer system channel ledger
- Primary responsibilities of the OSC is to orchestrate the creation of new channel(application channels)

- The process by OSC or Application channel is managed stays the same with initialization of the network
1. Genesis block gets created that holds the initial set of configuration
2. Config Tx stored in the Config Block
3. Peers read latest configuration from the Ledger
- Update transaction are isolated and avaliable only within that channel

#### Inspecting the latest channel config

1. Fetch the latest **Config Block**
- Create a temp folder `peer/simple-two-org/temp`
- `peer channel fetch config`
- `-c acmechannel`
- `-o localhost:7050`
- `./temp/config_block.pb`

2. Translate the block to **{JSON}**
- `configtxlator proto_decode`
- `--input ./temp/config_block.pb`
- `type common.Block`
- `> ./temp/config_block.json`

3. Extract the config using **./jq**
- Channel Configuration Path
- `export JQ_CONFIG_PATH=.data.data[0].payload.data.config.channel_group.groups.Orderer.values`
- `cat ./temp/config_block.json | jq $JQ_CONFIG_PATH`

### Policies

- Policies
- Hyperledger Fabric Policies embodies the rules for Access | Updates to the Network & Channel configurations
- Defined by the consortium
- Fine grained access control mechanism
- These are encoded in configtx.yaml > Genesis Block
- Control ___ can change (Rules)
1. WHAT...
- Network Configuration
- Channel Configuration
3. WHO...
- Administrator
- Member
- Application | client
5. HOW...
- Single Org driven
- Multi Org driven
- Examples:
- Add an Anchor Peer: Any admin from owner org
- Update Orderer system Channel: Majority admin form all org
- Add a new member: Any admin from any org

- Rules
- Rules are expressed as Bloolean expressions in terms of the Principals
- Principals
- Signer's role in the member organization
* 如果身份在網絡上進行交易，則應將其歸類為client。
* 如果身份處理諸如將對等方加入通道或簽署通道配置更新事務之類的管理任務，則應將其分類為admin。
* 如果身份認可或提交交易，則該身份應歸類為peer。
* 如果身份屬於訂購節點，則應將其分類為orderer。
- Example
- Rules applied at runtime

#### Policies Naming & Types
- Defined in appropriate section of configtx.yaml
- Defined as hierarchies
- Policies have Names

- Standard policy name
- Readers
read the channel
e.g., Query a chaincode
- Writers
write to the channel
e.g., Invoke a chaincode
- Admins
admin action on the channel
e.g., Add an Anchor peer
- Definition has two parts
- Type

| | Signature | Implicit meta |
| ---------- | ------------------------------------ | --------------------------------------------- |
| Rules | Boolean expressions | Refer to other policies(siga or meta) |
| Results | True or False | Aggregated from referred policies |
| Applicable | at all levels | for channel configuration (Not for Org level) |
| Use | Functions: OR, AND, OUTOF | Keywords: ANY, ALL, MAJORITY |
| Example |  |  |

- Signature
- OR
- AND
- OUTOF
- Implicit meta
Helps in avoiding duplication of policies and no need to update when new orgs are added
- ANY
- ALL
- MAJORITY
- Rule
- Boolean expression

#### Policy Encoding in Genesis