BSC(Binance Smart Chain) overview

BSC(Binance Smart Chain) overview

2023. 6. 14. 11:08ㆍBlockchain/Overview series

728x90

※ 원글 작성 : 22년 5월 30일

바이낸스는 Binance Chain(이하 BC) 메인넷을 출시한 후 smart contract 관련된 프로그래밍 확장성 및 VM 기능을 전문적으로 실행하는 Binance Smart Chain(이하 BSC)를 새롭게 출시했다. Binance Chain(이하 BC) 내에서 contract를 실행하면 coin/token의 transfer가 느려질 수 있기 때문에 BSC를 추가 하였다. BSC는 BC와 따로 떨어질 수 없는 관계인데, whitepaper를 참고하여 overview 해본다.

Design Principles

Standalone Blockchain
BSC는 BC의 L2 솔루션이 아닌 독립된 블록체인이다. BSC의 기본 기술 및 비즈니스 로직은 자체적으로 포함이 되어있어야 BC가 중단되더라도 BSC위의 contract는 잘 실행 될 수 있다.
Ethereum Compatibility
Ethereum 기반의 dApp, smart cotract를 수정없이 호환되도록 설계되어 있다.
Staking Involved Consensus and Governance
Staking 기반 합의는 PoW보다 더 환경친화적이며 governance의 의견 반영에 더 유연하다. PoW 시스템 보다 더 나은 네트워크 성능을 가질 수 있다.
Native Cross-Chain Communication
BC와 BSC는 각 블록체인 간 cross chain 통신에 대한 기본 지원이 가능하다. 통신 프로토콜은 양방향, 분산형, 무신뢰성이 보장되어 있다.

Consensus and Validator Quorum

Proof of Staked Authority

여러 블록체인에서 사용되고 있는 PoA(Proof of Authority)는 악의적이거나 해킹되어 있는 비잔틴 유저들에 대한 향상된 효율성과 내성으로 51% 공격에 대한 방어를 제공한다. 하지만 PoA의 경우 노드가 교대로 블록을 생성하고, 모든 권한을 갖고 있으며 PoW만큼 분산되어 있지 않기 때문에 보안 공격에 취약하다. 따라서, BSC는 DPoS를 함께 도입하여 탈중앙화를 증가시킨다.

블록은 제한된 validator set에 의해 생성된다.
Validator는 Ethereum의 clique 합의와 유사한 방식의 PoA로 블록을 생성한다.
Validator set은 스테이킹 기반 거버넌스에 따라 선출된다.

Validator Quorum

스테이킹에는 BNB 토큰을 사용하며, 가장 많이 스테이킹된 상위 21개 노드를 validator set으로 설정하며 24시간마다 변경된다.
BSC는 스테이킹 관리를 위해 BC를 사용하며, BC에는 BSC 전용 스테이킹 모듈이 존재한다. BC에서 BSC 스테이킹을 수락하고 가장 높이 스테이킹 된 노드 set을 계산한다. UTC 자정마다 BC는 ValidatorSetUpdate cross-chain 메시지를 발행하여 BSC에 validator set을 업데이트 한다. ValidatorSetUpdate가 포함된 추가 블록을 생성하는 동안 기존 BSC validator는 주기적으로 BSC에 중계 메시지를 확인한다. 메시지가 존재하는 경우 Epoch 이후에 validator set을 업데이트 한다. 예를 들어 BSC가 5초마다 블록을 생성하고 epoch 기간이 240블록이면 현재 validator set은 1200sec(20min) 내에 다음 epoch에 대한 validator set을 확인한다.

Token Economy

BC와 BSC는 BNB 및 BEP2 토큰에 대해 동일한 토큰 유니버스를 공유한다.

동일 토큰이 두 블록체인 네트워크에서 순환 가능하며 cross-chain 통신을 통해 양방향 전환이 가능하다.
동일한 토큰의 총 순환(circulation)은 두 네트워크 모두에서 관리되어야 한다. 토큰의 총 공급은 BSC와 BC 상의 총 토큰 양과 같아야 한다.
토큰은 초기에 ERC20 토큰과 유사한 형식으로 BSC에서 생성되며, BEP2로 BC에서 생성될 수 있다.

Native Token

BNB는 BSC에서 실행되어 BSC, BC 모두에서 네이티브 토큰으로 유지된다. 즉, BNB가 BC 및 Binance DEX에 대한 수수료를 지불하는데 사용되며, BSC smart contract 배포 수수료, BSC validator에 staking 보상, BC 및 BSC를 통한 cross-chain 작업에 사용된다.

Seed Fund

일정량의 BNB는 생성단계에서 BC에서 burn되고 BSC에서 mint된다. 해당 BNB는 genesis 블록이후 BSC에서 순환되는 seed fund이며, 초기 BC-BSC relayer 및 validator set으로 전달된다. Seed fund는 cross-chain 메커니즘으로 BC에서 BSC로 더 많은 BNB를 전송하기 위해 초기 단계에서 수수료로 사용된다.
BNB cross-chain transfer 중 BC to BSC는 일반적으로 source addr에서 시스템 제어 주소로 BC에 BNB를 lock하고 contract에서 해당 금액을 unlock한다. BSC to BC는 BSC의 source addr에서 BNB를 contract로 lock하고 잠긴 만큼 시스템 주소에서 target addr로 해제한다.

Other Tokens

BC는 BEP2, BEP8 토큰을 지원한다. BSC에서는 ERC20 토큰을 지원하며, 여기서는 'BEP2E'라고 한다.

Token Binding

Binder는 BEP2토큰과 BSC BEP2E 토큰 contract/토큰을 연결하며, 이 연결 프로세스를 token binding이라 한다. 토큰 바인딩은 BEP2 및 BEP2E가 준비된 후 언제든지 발생할 수 있으며 토큰의 소유자는 실제로 사용 전까지 binding에 대해 신경 쓸 필요가 없다. Issuer는 BEP2/BEP2E 중 원하는 것을 먼저 생성 가능하며 생성된 후 binding 될 수 있다. BEP2 및 BEP2E를 binding하는 절차는 아래와 같다.

BEP2 토큰과 BEP2E 토큰이 동일한 양으로 각 블록체인에 존재하는지 확인한다.
두 블록체인의 초기 순환을 결정한다. 총 공급량이 S이고 BC의 예상 초기 순환 공급량이 K라고 할 때 소유자는 S-K 토큰을 BC의 시스템 제어 주소에 고정해야 한다.
K 토큰은 TokenHub(BSC contract)에 lock된다. BEP2E 토큰 issuer는 해당 토큰의 K만큼을 TokenHub에 lock하고 S-K 토큰이 BSC에서 순환하도록 해야 한다. 즉, 2개의 블록체인에 총 순환은 S로 유지된다.
BEP2 토큰 발행자는 BC에서 bind tx를 전송한다. 적절한 검증 후 트랜잭션이 성공적으로 실행되면 BC의 시스템 제어 주소로 S-K 토큰을 전송하고, relayer가 relay를 하기 위한 cross-chain bind 요청 패키지가 생성된다.
BSC relayer는 cross-chain bind 요청 패키지를 BSC TokenHub로 relay하고, 해당 요청 및 정보는 contract에 저장된다.
Contract 소유자와 토큰 소유자만 TokenHub contract의 특수 메서드(ApproveBind)를 실행, 바인딩 요청을 확인한다.
ApproveBind 메서드가 성공하면 TokenHub는 두개의 토큰이 바인딩된것을 마킹하고 BSC에서 동일한 순환을 공유한 state를 BC로 전파한다. 최종 확인 후 BEP2E contract 주소와 decimals는 BEP2토큰에 BC의 새로운 속성(attribute)로 기록되며 토큰은 두 블록체인으로 양방향 전송이 가능하다. ApproveBind가 실패하면 event가 BC로 전달되어 잠긴 토큰을 unlock하고 위 단계를 다시 시도한다.

Cross-Chain Transfer and Communication

BNB 체인에서 cross-chain 통신은 이중 사슬 구조를 활용할 수 있도록 해준다.

Croos-Chain Transfer

기본적인 로직은 아래와 같다.

Transfer-out 블록체인은 src 소유자 주소로 부터 토큰 amount를 시스템 제어 주소/계약으로 잠근다.
Transfer-in 블록체인은 시스템 제어 주소/계약에서 금액을 unlock하고 타겟 주소로 보낸다.

Cross-chain transfer 패키지 메시지는 BSC relayer와 BC Oracle relayer가 아래 정보를 확인할 수 있도록 해야 한다.

충분한 양의 토큰이 src 주소에서 제거되고 src 블록체인의 시스템 제어 주소/계약에 lock된다. 이는 target 블록체인에서 확인 가능하다.
시스템 제어 주소/계약에서 적절한 토큰이 unlock되고 target 블록체인의 target addr에 할당된다. 실패할 시 src 블록체인에서 확인 가능하여 locked 토큰을 unlock 가능하다.
Transafer가 완료된 후 성공 여부 관계 없이 블록체인 상의 총 순환 합은 변경되지 않는다.

BC to BSC Architecture

BC는 tendermint 기반이며, 최소 2/3(N+1)의 validators가 체인의 각 블록에 공동으로 서명하며, 블록 헤더 및 머클 증명 검증으로 블록 트랜잭션 및 state를 검증한다. 전송 프로토콜은 Light-Client Protocol로 구현되어 있다.
BC-BSC 통신은 BSC smart contract를 통해 구현된 onchain light client에서 검증된다. BC에서 일부 트랜잭션 및 state 변경이 발생한 후 트랜잭션이 cross-chain comm.을 트리거하면 cross-chain 패키지 메시지가 생성되고 BSC relayer가 "build-in system contracts"에 submit한다. Build-in system contract는 패키지를 확인하고 통과되면 트랜잭션을 실행한다.

BSC to BC Architecture

BSC는 Proof of Staking Authority 합의 프로토콜을 사용한다. 하나의 블록에는 하나의 validator 서명만 있기 때문에 한 블록으로 BSC의 데이터 검증을 하기 쉽지 않아서, 더 많은 블록을 확인해야 한다. BC의 validator quorum을 최대한 활용하기 위해 Oracle 블록체인과 유사한 아이디어를 채택했다.

BSC의 cross-chain comm. 요청은 BSC에 제출되어 트랜잭션으로 실행된다. 트랜잭션 실행 시 events를 내보내고 BC의 특정 Oracle에서 관찰 및 패키징 가능하다. 블록 헤더, 해시 및 머클 증명 대신 Oracle 패키지에는 sender, receiver 및 전송 금액 등 cross-chain 정보가 직접 포함된다.
Oracle의 보안을 보장하기 위해 BC의 validators는 "Oracle relayers"의 또다른 다른 quorum을 구성한다. BC의 각 validator는 oracle relayer로 전용 프로세스를 실행해야 한다. 이 oracle relayer는 동일한 validator key를 사용하여 BC에 Oracle과 같은 cross-chain comm. 패키지를 제출하고, 투표한다. 2/3(N+1) 이상의 oracle relayer 투표권에 의해 서명된 패키지는 동일한 validator quorum의 2/3(N+1)에 의해 서명된 블록만큼 보안이 보장된다.

동일한 validator quorum을 사용하여 BC에 light-client 코드를 저장하고 BC에 지속적으로 블록을 업데이트 한다. Oracle에는 order 지정 및 오류 처리를 보장하기 위해 oracle ID 및 유형이 있다.

Timeout and Error Handling

Relay된 패키지가 contract의 bug로 인해 BSC로 실행할 수 없는 등 cross-chain comm.이 실패하는 시나리오가 있다. 이 시나리오 상에서 timeout 및 error handling 로직이 사용된다.
사용자 및 시스템 오류 또는, 예상되는 예외의 경우 두 블록체인 네트워크가 자체적으로 복구되어야 한다. 예로 BC에서 BSC로의 transfer가 실패하면 BSC는 실패 event를 발생시키고, oracle relayers는 BC에서 refund를 실행한다. BSC에서 BC로의 transfer가 실패하면 BC relayer가 자금을 unlock하기 위해 relay할 refund 패키지를 발행한다.
Cross-chain comm.의 모든 단계에서 예기치 않은 에러가 발생할 때 relayers와 oracle relayers는 cross-chain 채널이 특정 seq.에 고정되어 있다. Timeout 기간이 지나면 relayer와 oracle relayer는 "SkipSequence" 트랜잭션을 요청할 수 있고, 중단된 seq.는 "Unexecutable"로 표시된다.

Cross-Chain Contract Event

CCCE(Cross-Chain Contract Event)는 smart contract가 contract 코드를 통해 직접 cross-chain transaction을 트리거 할 수 있도록 아래르 기반으로 설계 되었다.

General smart contract에서 호출 가능한 작업을 제공하기 위해 표준 시스템 계약(Standard system contracts)을 제공한다.
Standard event는 standard contract에 의해 발생될 수 있다.
Oracle relayer는 standard event를 capture할 수 있고, cross-chain 운영을 트리거 할 수 있다.
Code-managed address(account)는 BC에서 생성할 수 있으며, BSC의 contract에서 액세스 할 수 있다. ("Contract Address on BC_CAoB")

Standard operations

BSC to BC transfer : Standard contract를 통해서만 트리거되어 BSC에서 BC로의 transfer와 동일한 방식으로 구현된다. Fund는 이전 original contract의 CAoB를 포함하여, BC의 어떤 주소든지 transfer될 수 있다.
Transfer on BC : cross-chain transfer로 구현되지만 실제 transfer는 한 CAoB에서 다른 주소나 다른 CAoB로 이루어진다.
BC to BSC transfer : 2-path cross-chain comm.으로 구현된다. 첫번째 path는 BSC contract에 의해 트리거되어 BC로 transfer되고, 두번째 path에서 BC는 CAoB에서 BSC contract address로 BC to BSC cross-chain transfer를 실행한다. BSC contract는 두번째 path에서 들어오는 transfer에만 잔액을 증가시킨다.
IOC(Immediate-Or-Cancel) trade out : CAoB의 특정 자산을 취소하여 BSC로 다시 transfer 한다. BC는 IOC 주문을 transaction에 전송하여 relay event를 처리한다.
Auction trade out : BC가 CAoB의 특정 자산을 다른 자산으로 거래하도록 auction 주문을 보내고, auction이 끝나면 모든 결과를 BSC로 전송한다. Auction 기능은 BC에서 제공한다.

Relay

Relayer는 두 체인간에 cross-chain comm. 패키지를 제출해야 하며, 이기종 병렬 체인이기 때문에 두가지의 relay가 생성된다.

BSC relayers

BC to BSC에 사용된다. Relayer는 BSC에 등록하고 환불 가능한 BNB를 예금해야 하지만, 이를 제외하고는 누구나 실행 가능한 독립형 프로세스이다(BSC는 등록된 relayer의 요청만 수행). Relayer의 패키지는 BSC의 onchain light client에 의해 확인된다. Relay를 성공적으로 하기 위해서는 충분한 검증이 필요하며, BSC에서 가스비가 발생하므로 incentive가 있어야 한다.

Oracle relayers

BSC to BC에 사용된다. 각 validator는 반드시 orcal relayer를 실행해야 하며, validator set 중 하나만 실행해야 한다. 각 oracle relayer는 체인 state를 관찰하며, cross-chain comm. 패키지를 확인하면 요청에 대한 투표를 제출한다. BC validator의 투표권 2/3의 oracle relayer가 변경사항에 대해 투표 후 cross-chain 작업이 수행된다.
Oracle replayer는 BC에 cross-chain comm. 패키지를 제출하고 투표 전 BSC에서 finality 확인을 위해 블록 생성을 기다린다.

Conclusion

BC와 BSC는 상호 의존적인 관계이기 때문에 둘을 분리하여 운영할 수 없을것이다. Solidity 기반 smart contract 및 dApp을 지원할 수 있도록 ethereum 기반 BSC를 도입했고, tendermint 기반 BC에서 validator 를 관리하고 있다. BSC relayer와 oracle relayer를 설계하여 두 체인간의 cross-chain comm.을 지원하고 있어서 브리지 형태로 상호 간 BNB를 교환한다.

Binance 지갑을 통해 testnet에서 BSC to BC transfer를 진행해보았다.

To address가 "TokenHub"라는 0x0000...0001004의 주소로 전달이 되고 이 토큰허브에서 BSC의 BNB를 lock 후 BC로 전달되는 구조로 보인다.

BC explorer에서도 transaction을 확인할 수 있다.

{
  "chainId": 97,
  "sequence": 20251,
  "payload": [
    {
      "channelId": 3,
      "sequence": 19667,
      "payload": {
        "packageType": 0,
        "crossChainFee": 1000000,
        "content": {
          "symbol": "BNB",
          "contractAddress": "0x0000000000000000000000000000000000000000",
          "amounts": [
            1000000
          ],
          "receiverAddresses": [
            "tbnb19...8a3"
          ],
          "refundAddresses": [
            "0xdc1...24d"
          ],
          "expireTime": 1653883432093
        }
      }
    }
  ],
  "validatorAddress": "bva193t8pkhm2sxw5uy5ypesygda8rzsk25ghc336t"
}

재밌는 개념을 선택하였고 relayer를 통해 이종체인 간 자산 교환을 구현했지만, bridge의 경우 axie처럼 해커들의 공격목표가 될 수 있기 때문에 이를 방지하기 위한 보안 기능이 중요할 것으로 보인다.

참고
https://github.com/bnb-chain/whitepaper/blob/master/WHITEPAPER.md