$$config title: 하이퍼레저 패브릭 설정 및 관련 내용 정리 keywords: - IT - ... $$ - 채널 내에서 패브릭 네트워크 상의 참여자들은 그 모든 멤버가 특정 트랜잭션만 볼 수 있는 서브 네트워크를 만듭니다. - 블록의 유효성을 검증하기 위해선 과반수의 동의가 필요 - orderer를 포함한 해당 조직들의 과반수의 동의가 필요한것 - 외부의 누군가, 내부의 사용자 모두 해당 트랜잭션의 내용은 확인 할 수 없다 # Channel - ex) 이더리움 네트워크 ## Chaincode - 스마트 컨트랙트 ## ORG - Organization - 조직은 원장을 관리하고, 트랜잭션을 생성하고, 스마트 계약(또는 체인코드)을 실행하는 등의 역할을 하는 피어 노드를 포함합니다. 조직은 또한 자신의 멤버십 서비스 제공자(Membership Service Provider, MSP)를 갖고, 이를 통해 조직의 신원을 관리하고 검증 ## peer ### peer의 User - peer의 user는 해당 조직의 멤버십 서비스 제공자 (msp)에 의해 발급된 신원을 나타낸다. - 이들 신원은 네트워크 참가자를 나타내며, 각각 다른 역할, 권한 및 특권을 가질 수 있다. ``` ex) Q. peer1의 admin은 앵커피어인가 ? A. admin의 신원과 앵커피어는 다른 개념이다. admin 신원은 특정 조직 내 특정 권한을 가진 신원이고 체인코드를 배포하거나, msp 설정을 변경하는 등의 관리 작업을 수행할 수 있다. 하지만 앵커피어는 조직의 대표 Peer로써, 다른 조직의 Peer들이 해당 조직의 Peer들과 통신할 때 사용하는 첫 번째 접점이다. 즉, 다른 조직이 특정 조직과 통신하려 할 때 그들은 먼저 앵커피어와 연결을 시도한다. => 하나의 조직을 구성 하고 그 내부에는 orderer, org1, org2가 있음 이것은 peer 조직 그렇다면 org1을 앵커피어로 지정하면 다른 조직과 소통하는데 용이 또한 orderer는 블록을 생성하고 분배하기 위한 피어 보통은 1. 트랜잭션 발생 : 조직이 체인코드(스마트 컨트랙트)를 실행하려 할 때 , 이 체인코드는 네트워크의 여러 조직의 Peer에 배포되어야하는데 이 경우 앵커피어를 통해 배포 된다 2. 블록의 공유: 블록체인 네트워크에서 트랜잭션이 검증되고 새로운 블록이 생성되면, 이 블록은 네트워크의 모든 조직 peer에게 배포되어야한다. 이때도 각 조직의 앵커 피어를 통해 이루어지게 된다. 앵커피어가 아닌 피어(peer)도 하이퍼레저 패브릭 네트워크에서 중요한 역할을 수행합니다. 앵커피어가 아닌 피어는 다음의 주요 역할을 수행합니다: 1. **트랜잭션 처리:** 모든 피어는 체인코드(스마트 계약)를 실행하고, 트랜잭션을 시뮬레이션하며, 트랜잭션 제안에 대해 승인 또는 거절의 응답을 생성합니다. 2. **블록 생성 및 유효성 검사:** 피어는 블록을 수신하고, 블록에 포함된 모든 트랜잭션의 유효성을 검사합니다. 피어는 트랜잭션이 무결한지, 순서가 올바른지, 더블 스펜딩이 발생하지 않았는지 등을 확인합니다. 3. **장부 유지:** 모든 피어는 블록체인의 사본을 유지하며, 최신의 상태를 추적합니다. 앵커피어는 조직 간에 통신을 위한 "대표" 역할을 하는 피어입니다. 즉, 앵커피어는 네트워크 안에서 다른 조직의 앵커피어와 정보를 교환합니다. 그러나 앵커피어가 아닌 피어들도 그들의 조직 내에서 중요한 역할을 수행하며, 트랜잭션의 처리, 블록의 검증, 그리고 상태의 유지 등의 역할을 합니다. ``` ``` peer ? user ? peer는 실제 블록체인의 노드를 나타내고 그 안에있는 user는 네트워크에서 트랙잭션을 제출하고 검증할 수 있는 개체를 나타낸다 즉 peer는 노드 사용자는 사용자는 트랜잭션을 제안하거나, 체인코드 (블록체인 네트워크 내에서 실행되는 스마트 계약)를 실행하거나, 블록체인의 상태를 조회하는 등의 작업을 수행할 수 있다 즉 사용자는 해당 피어들을 사용하는 주체 해당 신원과 권한은 MSP에 의해 관리되고 인증된다 ``` ``` orderer은 블록을 생성하고 분배하는 역할을 담당 # orderer가 블록을 생산하는 과정 1. **트랜잭션 제안**: 사용자는 체인코드를 호출하여 네트워크에 트랜잭션을 제안합니다. 이 트랜잭션은 블록에 추가되기 전에 검증되어야 합니다. 2. **트랜잭션 검증**: 제안된 트랜잭션은 피어 노드에 도착하며, 각 피어는 트랜잭션의 유효성을 검증합니다. 유효성 검사는 체인코드의 규칙에 따라 수행됩니다. 3. **트랜잭션 패키징**: 유효한 트랜잭션은 Orderer에게 전달되어 패키징됩니다. Orderer는 여러 개의 트랜잭션을 하나의 블록에 묶어줍니다. 4. **블록 생성**: Orderer는 패키징된 트랜잭션을 블록으로 묶어 새로운 블록을 생성합니다. 이 블록에는 트랜잭션의 데이터와 메타데이터가 포함됩니다. 5. **블록 분배**: 생성된 블록은 네트워크의 피어 노드에게 분배됩니다. Orderer는 블록을 전송하고 피어 노드는 블록을 수신하여 승인 및 커밋 프로세스를 진행합니다. 6. **블록 커밋**: 피어 노드는 블록의 유효성을 다시 검증한 후, 해당 블록을 블록체인 장부에 영구적으로 기록합니다. 이로써 새로운 블록의 데이터가 장부에 추가되며, 네트워크의 상태가 업데이트됩니다. 이렇게 Orderer는 트랜잭션을 받아 패키징하여 블록을 생성하고, 생성된 블록을 네트워크의 피어 노드에게 분배합니다. 피어 노드는 블록을 검증하고 커밋하여 블록체인에 새로운 데이터를 추가합니다. 이러한 과정을 통해 블록체인 네트워크는 투명하고 불변의 트랜잭션 기록을 유지하며, 여러 참가자들이 공통된 상태를 유지할 수 있습니다. ``` # Sample Code - 하이퍼레저 패브릭에서 제공한 샘플코드를 보면 조직을 구성할 때 2개의 소 조직으로 나눈다 - 블록을 생성하고 분배하는 orderer - 노드라고도 불리우는 peer - 만약 다른 조직과의 소통이 필요하다면 해당 조직 내부의 앵커피어를 설정해서 상호작용 할 수 있게 해야한다 ``` 네트워크를 구현해두면 이후에 토큰 개발은 스마트 컨트랙트인 체인코드만 잘 구현하면 수월 ``` ``` Hyperledger Fabric 네트워크에서 트랜잭션의 내용을 확인할 수 있는 사람은 다음과 같습니다: 1. 트랜잭션을 생성한 유저: 트랜잭션을 생성한 유저는 자신이 생성한 트랜잭션의 결과 및 변경된 상태를 확인할 수 있습니다. 유저는 자신이 생성한 트랜잭션의 ID를 추적하고, 해당 트랜잭션의 실행 결과 및 상태를 조회하여 확인할 수 있습니다. 2. 트랜잭션의 수신자 또는 관련된 조직의 피어: 트랜잭션의 수신자 또는 해당 트랜잭션과 관련된 조직의 피어는 해당 트랜잭션의 실행과 변경된 상태를 확인할 수 있습니다. 트랜잭션이 수신자에게 영향을 주는 경우, 해당 피어는 트랜잭션의 실행 결과와 상태를 조회하여 확인할 수 있습니다. 3. 네트워크 관리자: 네트워크 관리자는 네트워크의 전반적인 상태 및 트랜잭션의 내용을 확인할 수 있습니다. 네트워크 관리자는 블록체인 익스플로러 또는 네트워크 관리 도구를 사용하여 트랜잭션의 내용, 블록의 내용, 체인코드의 상태 등을 조회하고 확인할 수 있습니다. 4. 허용된 감사 및 감사 규정을 충족하는 제3자: Hyperledger Fabric 네트워크의 트랜잭션은 기밀성을 유지하기 위해 암호화됩니다. 그러나 허용된 감사 규정을 충족하고 필요한 권한을 가진 제3자는 특정 트랜잭션의 내용을 확인할 수 있는 경우가 있습니다. 이는 네트워크의 감사 및 규정 요구 사항에 따라 다를 수 있습니다. 위와 같이, 트랜잭션의 내용을 확인할 수 있는 사람은 주로 트랜잭션을 생성한 유저, 트랜잭션의 수신자 또는 관련된 조직의 피어, 네트워크 관리자, 그리고 허용된 감사 및 감사 규정을 충족하는 제3자입니다. 이러한 권한과 접근 제어는 네트워크의 보안과 기밀성을 유지하는 데 중요한 역할을 합니다. ``` # configtx에 대한 설정 파일 ``` # 조직 구성 orderer : 블록을 생성하고 배포하는 용도의 조직 user : 사용자의 신원을 검증하고 확인하는 조직 peer : 트랜잭션에 대한 유효성을 검증하기 위한 조직 peer에 대한 역할을 이 조직만이 가지고 있음 ``` --- ``` Organizations: - &OrdererOrg Name: OrdererOrg ID: OrdererMSP MSPDir: ../organizations/ordererOrganizations/example.com/msp Policies: Readers: Type: Signature Rule: "OR('OrdererMSP.member')" Writers: Type: Signature Rule: "OR('OrdererMSP.member')" Admins: Type: Signature Rule: "OR('OrdererMSP.admin')" OrdererEndpoints: - orderer.example.com:7050 - &UserOrg Name: UserOrgMSP ID: UserOrgMSP MSPDir: ../organizations/peerOrganizations/userorg.example.com/msp Policies: Readers: Type: Signature Rule: "OR('UserOrgMSP.admin', 'UserOrgMSP.peer', 'UserOrgMSP.client')" Writers: Type: Signature Rule: "OR('UserOrgMSP.admin', 'UserOrgMSP.client')" Admins: Type: Signature Rule: "OR('UserOrgMSP.admin')" - &PeerOrg Name: PeerOrgMSP ID: PeerOrgMSP MSPDir: ../organizations/peerOrganizations/peerorg.example.com/msp Policies: Readers: Type: Signature Rule: "OR('PeerOrgMSP.admin', 'PeerOrgMSP.peer', 'PeerOrgMSP.client')" Writers: Type: Signature Rule: "OR('PeerOrgMSP.admin', 'PeerOrgMSP.client')" Admins: Type: Signature Rule: "OR('PeerOrgMSP.admin')" Endorsement: Type: Signature Rule: "OR('PeerOrgMSP.peer')" Capabilities: Channel: &ChannelCapabilities V2_0: true Orderer: &OrdererCapabilities V2_0: true Application: &ApplicationCapabilities V2_5: true Application: &ApplicationDefaults Organizations: - *UserOrg - *PeerOrg Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" LifecycleEndorsement: Type: ImplicitMeta Rule: "MAJORITY Endorsement" Endorsement: Type: ImplicitMeta Rule: "MAJORITY Endorsement" Capabilities: <<: *ApplicationCapabilities Orderer: &OrdererDefaults OrdererType: etcdraft EtcdRaft: Consenters: - Host: orderer.example.com Port: 7050 ClientTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt ServerTLSCert: ../organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt Addresses: - orderer.example.com:7050 BatchTimeout: 2s BatchSize: MaxMessageCount: 10 AbsoluteMaxBytes: 98 MB PreferredMaxBytes: 512 KB Organizations: - *OrdererOrg Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" Capabilities: <<: *OrdererCapabilities Channel: &ChannelDefaults Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" Capabilities: <<: *ChannelCapabilities Profiles: TwoOrgsApplicationGenesis: <<: *ChannelDefaults Orderer: <<: *OrdererDefaults Organizations: - *OrdererOrg Capabilities: *OrdererCapabilities Application: <<: *ApplicationDefaults Organizations: - *UserOrg - *PeerOrg Capabilities: *ApplicationCapabilities ``` --- ``` 1. Organizations: - `&OrdererOrg`: Orderer 조직에 대한 설정입니다. - `Name`: Orderer 조직의 이름입니다. - `ID`: MSP(Membership Service Provider)에서 사용할 ID입니다. - `MSPDir`: Orderer 조직의 MSP 디렉토리 경로입니다. - `Policies`: Orderer 조직의 정책 설정입니다. `Readers`, `Writers`, `Admins`에 대한 서명 기반의 규칙이 정의됩니다. - `OrdererEndpoints`: Orderer 엔드포인트의 주소와 포트를 지정합니다. - `&UserOrg`: 사용자 조직에 대한 설정입니다. - `Name`: 사용자 조직의 이름입니다. - `ID`: MSP에서 사용할 ID입니다. - `MSPDir`: 사용자 조직의 MSP 디렉토리 경로입니다. - `Policies`: 사용자 조직의 정책 설정입니다. `Readers`, `Writers`, `Admins`에 대한 서명 기반의 규칙이 정의됩니다. - `&PeerOrg`: 피어 조직에 대한 설정입니다. - `Name`: 피어 조직의 이름입니다. - `ID`: MSP에서 사용할 ID입니다. - `MSPDir`: 피어 조직의 MSP 디렉토리 경로입니다. - `Policies`: 피어 조직의 정책 설정입니다. `Readers`, `Writers`, `Admins`, `Endorsement`에 대한 서명 기반의 규칙이 정의됩니다. 2. Capabilities: - Channel, Orderer, Application의 기능(capability) 설정을 정의합니다. 각각 `V2_0` 및 `V2_5`를 활성화하도록 설정되어 있습니다. 3. Application: 애플리케이션 관련 설정입니다. - `Organizations`: 채널에 참여하는 조직들을 지정합니다. 사용자 조직(`UserOrg`)과 피어 조직(`PeerOrg`)을 포함합니다. - `Policies`: 애플리케이션 관련 정책 설정입니다. `Readers`, `Writers`, `Admins`, `LifecycleEndorsement`, `Endorsement`에 대한 암묵적 정책 규칙이 정의됩니다. 4. Orderer: 오더러 관련 설정입니다. - `OrdererType`: 오더러 유형을 지정합니다. `etcdraft`를 사용합니다. - `EtcdRaft`: `etcdraft` 오더러 유형의 설정입니다. - `Consenters`: 오더러 동의자(Consenter)의 설정입니다. 주문서 동의자의 호스트, 포트, 클라이언트 및 서버 TLS 인증서 경로를 지정합니다. - `Addresses`: 오더러의 주소와 포트를 지정합니다. - `BatchTimeout`: 트랜잭션 배치의 타임아웃 값을 지정합니다. - `BatchSize`: 트랜잭션 배치의 크기를 지정합니다. - `Organizations`: 오더러 조직을 지정합니다. - `Policies`: 오더러 관련 정책 설정입니다. 5. ChannelDefaults: - `Policies`: 채널 관련 정책 설정입니다. `Readers`, `Writers`, `Admins`에 대한 암묵적 정책 규칙이 정의됩니다. - `Capabilities`: 채널 수준의 기능 설정을 정의합니다. 6. Profiles: 프로파일 설정입니다. `TwoOrgsApplicationGenesis` 프로파일은 채널과 오더러, 애플리케이션에 대한 기본 설정을 포함합니다. 해당 설정 파일은 주로 Hyperledger Fabric 네트워크의 구성을 위한 것으로, 조직과 채널의 구성, 정책, 기능 설정 등을 정의합니다. 이를 통해 네트워크 참여자들은 권한에 따라 트랜잭션을 읽거나 쓰는 등의 작업을 수행할 수 있습니다. ``` --- ``` 각각의 정책에 대해 설명드리겠습니다: 1. Readers: - `Readers` 정책은 채널에서 데이터를 읽을 수 있는 사용자의 권한을 정의합니다. - `Readers` 정책에는 MSP 멤버십에 속한 사용자들이 포함됩니다. - 서명 기반의 정책 규칙(`Signature`)을 사용하여 사용자가 속한 MSP의 관리자 또는 피어, 클라이언트로 등록되어 있을 경우 데이터를 읽을 수 있습니다. 2. Writers: - `Writers` 정책은 채널에 데이터를 쓸 수 있는 사용자의 권한을 정의합니다. - `Writers` 정책에는 MSP 멤버십에 속한 사용자들이 포함됩니다. - 서명 기반의 정책 규칙(`Signature`)을 사용하여 사용자가 속한 MSP의 관리자 또는 클라이언트로 등록되어 있을 경우 데이터를 쓸 수 있습니다. 3. Admins: - `Admins` 정책은 채널과 관련된 관리 작업을 수행할 수 있는 사용자의 권한을 정의합니다. - `Admins` 정책에는 MSP 멤버십에 속한 관리자들이 포함됩니다. - 서명 기반의 정책 규칙(`Signature`)을 사용하여 사용자가 속한 MSP의 관리자로 등록되어 있을 경우 관리 작업을 수행할 수 있습니다. 4. Endorsement: - `Endorsement` 정책은 트랜잭션에 대한 유효성 검증을 수행할 수 있는 피어의 권한을 정의합니다. - `Endorsement` 정책에는 MSP 멤버십에 속한 피어들이 포함됩니다. - 서명 기반의 정책 규칙(`Signature`)을 사용하여 사용자가 속한 MSP의 피어로 등록되어 있을 경우 트랜잭션에 대한 유효성 검증을 수행할 수 있습니다. 이러한 정책은 Hyperledger Fabric 네트워크에서 사용자 및 피어의 역할과 권한을 관리하기 위해 설정됩니다. 각각의 정책은 MSP의 관리자, 피어 및 클라이언트 등의 역할에 따라 읽기, 쓰기, 관리 및 유효성 검증 작업에 대한 권한을 부여합니다. ``` ``` V2.0과 V2.5는 Hyperledger Fabric의 기능적인 측면을 나타내는 버전 번호입니다. 각 버전은 Fabric 네트워크의 기능 및 기능 향상을 나타냅니다. 1. V2.0: - V2.0은 Hyperledger Fabric의 초기 버전 중 하나입니다. - V2.0에서는 채널 기능, 체인코드 업그레이드, 채널 업그레이드, 피어 조직 관리 등의 주요 기능이 도입되었습니다. - 이 버전에서는 체인코드의 업그레이드와 관련된 기능을 개선하고, 채널 구성 업데이트에 대한 성능 및 기능 향상도 이루어졌습니다. - 또한, 보안 기능과 MSP(Membership Service Provider) 관리 등의 측면에서도 개선이 이루어졌습니다. 2. V2.5: - V2.5는 Hyperledger Fabric의 더 최신 버전 중 하나입니다. - V2.5에서는 기존의 기능들에 대한 개선과 새로운 기능들이 추가되었습니다. - 이 버전에서는 더욱 강화된 보안 기능과 인증 및 신원 관리, 데이터 프라이버시, 체인코드 생명주기 관리 등에 대한 기능이 포함되었습니다. - 또한, 피어 및 주문자 노드의 확장성 및 성능 향상, 피어 구성 및 관리 등의 개선 사항도 포함되어 있습니다. 각 버전의 선택은 Fabric 네트워크에서 필요한 기능과 요구 사항에 따라 결정됩니다. 새로운 버전으로 업그레이드할 때는 호환성 및 변경 사항에 유의하여 네트워크 업그레이드를 수행해야 합니다. ``` --- ``` BatchTimeout 및 BatchSize는 Hyperledger Fabric에서 트랜잭션 처리를 효율적으로 관리하기 위한 설정입니다. - BatchTimeout: BatchTimeout은 트랜잭션을 묶어서 블록으로 커밋하는 주기를 정의합니다. 즉, 얼마나 많은 시간동안 트랜잭션을 수집하여 하나의 블록으로 만들지를 결정합니다. 이 값은 시간 간격을 밀리초 단위로 지정하며, 기본값은 2초입니다. BatchTimeout이 작을수록 트랜잭션이 빠르게 커밋되지만, 너무 작게 설정하면 트랜잭션 수집 및 블록 생성에 대한 오버헤드가 발생할 수 있습니다. - BatchSize: BatchSize는 하나의 블록에 포함될 트랜잭션의 수를 정의합니다. 기본적으로는 트랜잭션의 개수를 기준으로 지정되며, 기본값은 10입니다. BatchSize가 클수록 더 많은 트랜잭션을 하나의 블록에 포함시킬 수 있으며, 이는 블록 생성 및 블록 처리 성능을 향상시킬 수 있습니다. 그러나 너무 큰 BatchSize는 블록의 크기를 증가시키고, 네트워크 대역폭과 저장소 요구 사항에 영향을 줄 수 있습니다. BatchTimeout 및 BatchSize는 실제 환경에서 트랜잭션 처리량, 네트워크 지연 및 대역폭 등의 요인을 고려하여 조정되어야 합니다. 이를 통해 효율적인 트랜잭션 처리와 블록 생성을 달성할 수 있습니다. ``` # 인증서 생성을 위한 해당 설정 파일 - fabric-ca-server-config.yaml은 fabric-CA 서버의 설정 파일이다. - 경로는 test-network 기준 test-network/organizations/fabric-ca에 존재한다 ``` # ``` ``` 1.Fabric-CA 클라이언트 구성 - 사용자 등록 및 인증서 발급에 사용 # user-client.yaml cryptoconfig: path: ../organizations/peerOrganizations/userorg.example.com/ credentialStore: path: /tmp/fabric-ca-client/user wallet: mywallet url: http://localhost:7054 mspdir: ../organizations/peerOrganizations/userorg.example.com/users/Admin@userorg.example.com/msp 2. 사용자 등록을 위한 인증서 요청을 생성 - fabric-ca-client register --id.name user1 --id.type user --id.affiliation org1.department1 --id.attrs "attr1=value1:ecert" --id.secret password --id.maxenrollments -1 ``` --- ``` 해당 명령어에 대한 설명 - register: 사용자 등록 명령어를 실행합니다. - --id.name user1: 등록할 사용자의 이름을 지정합니다. 여기서는 "user1"이라는 이름을 사용하고 있습니다. - --id.type user: 등록할 사용자의 유형을 지정합니다. 여기서는 "user" 유형을 사용하고 있습니다. - --id.affiliation org1.department1: 등록할 사용자의 소속을 지정합니다. 여기서는 "org1.department1"에 속한 사용자로 등록하고 있습니다. - --id.attrs "attr1=value1:ecert": 등록할 사용자에 대한 속성을 지정합니다. 여기서는 "attr1"이라는 속성에 "value1" 값을 할당하고 있습니다. "ecert"은 해당 속성이 ECert (Enrollment Certificate)에 추가되어 저장될 것임을 나타냅니다. - --id.secret password: 등록할 사용자의 비밀번호를 지정합니다. 여기서는 "password"라는 비밀번호를 사용하고 있습니다. - --id.maxenrollments -1: 사용자가 수행할 수 있는 최대 enrollments(즉, 인증서 갱신) 횟수를 지정합니다. 여기서는 -1을 사용하여 제한 없이 enrollments를 수행할 수 있도록 설정하고 있습니다. ```

게시글 상세