제가 공부하기 위하여 적어놓았습니다~! 혹시 이상한 부분 있거나 누락된 부분이 있으면 댓글로 알려주세요 :)

Binance Smart Chain: 스마트 컨트랙트를 가능하게 하는 병렬 Binance 체인

버전 0.1

2020년 4월 17일

동기

2019년 4월 메인넷 커뮤니티 출시 후, Binance 체인은 그 높은 속도와 큰 처리량 설계를 보여주었습니다. Binance 체인의 주요 초점인 네이티브 탈중앙화 애플리케이션("dApp") Binance DEX는 큰 용량 헤드룸으로 수백만 거래량을 짧은 시간에 처리하며 낮은 지연 시간 매칭을 입증했습니다.

유연성과 사용성은 종종 성능과 반비례 관계에 있습니다. 편리한 디지털 자산 발행 및 거래 장소 제공에 중점을 두면서도 제한이 따릅니다. Binance 체인에서 가장 요청된 기능은 프로그램 확장 가능성, 즉 스마트 컨트랙트 및 가상 머신 기능입니다. 디지털 자산 발행자 및 소유자는 자산에 새로운 탈중앙화 기능을 추가하거나 커뮤니티 거버넌스 및 활동을 도입하는 데 어려움을 겪고 있습니다.

Binance 체인에 스마트 컨트랙트 기능을 추가하려는 높은 수요에도 불구하고 이는 어려운 결정입니다. 스마트 컨트랙트의 실행은 교환 기능을 늦출 수 있고 거래에 비결정적 요소를 추가할 수 있습니다. 그러한 타협을 감수할 수 있다면 Tendermint를 기반으로 새로운 가상 머신 사양을 도입하는 것이 간단한 아이디어일 수 있습니다. 하지만 이는 모든 기존 dApp 커뮤니티의 학습 요구사항을 증가시킬 것입니다.

우리는 현재 Binance 체인의 병렬 블록체인을 제안하여 네이티브 DEX 블록체인의 높은 성능을 유지하고 동시에 친화적인 스마트 컨트랙트 기능을 지원합니다.

설계 원칙

병렬 블록체인이 Binance 체인 생태계에 생성된 후, 두 블록체인은 다른 서비스를 제공하기 위해 나란히 실행될 것입니다. 새로운 병렬 체인은 "Binance Smart Chain"("BSC"로 짧게 표현됨)이라고 불리며, 기존 메인넷은 "Binance Chain"("BC"로 짧게 표현됨)으로 명명됩니다.

BSC의 설계 원칙은 다음과 같습니다:

독립적 블록체인: 기술적으로 BSC는 Layer2 솔루션이 아닌 독립적인 블록체인입니다. 대부분의 BSC 기본 기술 및 비즈니스 기능은 자체적으로 포함되어 있어 BC가 잠시 중단되더라도 잘 작동할 수 있습니다.
이더리움 호환성: 첫 번째 실용적이고 널리 사용되는 스마트 컨트랙트 플랫폼은 이더리움입니다. 상대적으로 성숙한 애플리케이션과 커뮤니티의 이점을 활용하기 위해 BSC는 기존 이더리움 메인넷과 호환됩니다. 이는 대부분의 dApp, 생태계 구성 요소 및 도구가 BSC와 함께 작동하며 거의 변경이 필요 없거나 최소한의 변경만 필요하다는 것을 의미합니다. BSC 노드는 비슷하거나 약간 높은 하드웨어 사양과 운영 기술을 필요로 할 것입니다.
스테이킹이 포함된 컨센서스 및 거버넌스: 스테이킹 기반의 컨센서스는 환경 친화적이며 커뮤니티 거버넌스에 더 유연한 옵션을 제공합니다. 이 컨센서스는 전체 작업 증명 방식보다 더 나은 네트워크 성능을 가능하게 할 것으로 예상됩니다. 즉, 더 빠른 블로킹 시간과 더 높은 거래 용량을 의미합니다.
네이티브 크로스체인 통신: BC와 BSC는 두 블록체인 간의 통신을 위해 네이티브 지원으로 작성될 것입니다. 통신 프로토콜은 양방향, 분산형 및 무신뢰해야 합니다. 이것은 주로 BC와 BSC 간에 디지털 자산을 이동하는 데 중점을 둘 것입니다.

컨센서스 및 검증자 쿼럼

이더리움보다 짧은 블로킹 시간을 가져야 합니다. 예를 들어 5초 혹은 그보다 더 짧게.
거래의 최종성을 확정하는 데 필요한 시간이 제한되어야 합니다. 예를 들어 약 1분 수준 또는 그보다 짧게.
인플레이션이 없으며, 블록 보상은 가스 수수료에서 나옵니다. 가스는 BNB로 지불됩니다.
가능한 한 이더리움과 호환되도록 시스템을 구성해야 합니다.
현대적인 스테이킹 기반 네트워크 거버넌스를 갖춰야 합니다.

스테이크 기반 권한 증명

작업 증명(PoW)이 분산된 네트워크를 구현하는 실용적인 메커니즘으로 입증되었지만, 환경에 친화적이지 않으며 보안을 유지하기 위해 많은 참여자가 필요합니다.

이더리움과 다른 네트워크들, 예를 들어 MATIC Bor, TOMOChain, GoChain, xDAI는 테스트넷과 메인넷을 포함한 다양한 시나리오에서 권한 증명(PoA) 또는 그 변형을 사용합니다. PoA는 51% 공격에 대한 일정 수준의 방어를 제공하며, 효율성과 비잔틴 플레이어(악의적이거나 해킹된)에 대한 허용도를 향상시킵니다. 이는 기본적으로 선택하기 쉬운 옵션으로 작용합니다.

한편 PoA 프로토콜은 PoW만큼 분산되지 않았다는 점에서 가장 비판받고 있으며, 블록을 생성하는 권한을 갖는 검증자들이 부패하거나 보안 공격에 취약할 수 있습니다. 다른 블록체인들, 예를 들어 EOS와 Cosmos는 토큰 홀더가 검증자 세트를 투표하고 선출할 수 있는 대리 스테이킹(Deputy Proof of Stake, DPoS)의 다양한 형태를 도입합니다. 이는 분산화를 증가시키고 커뮤니티 거버넌스를 선호합니다.

BSC는 여기에서 DPoS와 PoA를 결합하여 컨센서스를 제안합니다. 그래서:

블록은 제한된 검증자 세트에 의해 생성됩니다.
검증자는 이더리움의 Clique 컨센서스 엔진과 유사한 방식으로 PoA 방식으로 차례대로 블록을 생성합니다.
검증자 세트는 스테이킹 기반 거버넌스를 통해 선출되고 탈락됩니다.

검증자 쿼럼

제네시스 단계에서 몇몇 신뢰할 수 있는 노드가 초기 검증자 세트로 운영될 것입니다. 블로킹이 시작된 후, 누구나 검증자로 선출될 수 있는 후보자로 참여할 수 있습니다. 스테이킹 상태는 상위 21개의 가장 높은 스테이크를 가진 노드를 다음 검증자 세트로 결정하며, 이러한 선거는 24시간마다 반복됩니다.

BNB는 BSC에 스테이크하기 위해 사용되는 토큰입니다.

BSC와의 호환성과 미래의 컨센서스 프로토콜로 업그레이드 가능성을 유지하기 위해, BSC는 스테이킹 관리를 위해 BC에 의존합니다(아래 "스테이킹 및 거버넌스" 섹션을 참조하십시오). BSC에 대한 전용 스테이킹 모듈이 BC에 있으며, BNB 홀더로부터 BSC 스테이킹을 받아 최고 스테이크 노드 세트를 계산합니다. 매일 UTC 자정에, BC는 검증자 세트 업데이트를 통지하는 검증 가능한 ValidatorSetUpdate 크로스체인 메시지를 발행합니다.

추가 블록을 생성하는 동안, 기존 BSC 검증자는 주기적으로 BSC로 중계된 ValidatorSetUpdate 메시지가 있는지 확인합니다. 만약 있다면, 그들은 에포크 기간 후에 검증자 세트를 업데이트할 것입니다. 예를 들어, BSC가 5초마다 블록을 생성하고 에포크 기간이 240블록이라면, 현재 검증자 세트는 다음 에포크의 검증자 세트를 1200초(20분) 후에 확인하고 업데이트할 것입니다.

보안 및 최종성

½N+1 이상의 검증자가 정직하다면 PoA 기반 네트워크는 일반적으로 안전하고 적절하게 작동합니다. 그러나 일정량의 비잔틴 검증자가 여전히 네트워크를 공격할 수 있습니다. BC만큼 안전하게 보호하기 위해, BSC 사용자는 ⅔N+1 이상 다른 검증자에 의해 봉인된 블록을 받을 때까지 기다리도록 권장됩니다. 이 방법으로, BSC는 BC와 유사한 보안 수준을 신뢰할 수 있고 ⅓*N 미만의 비잔틴 검증자를 견딜 수 있습니다.

21개의 검증자가 있고 블록 시간이 5초인 경우, ⅔N+1 다른 검증자 봉인은 75초의 시간이 필요합니다. BSC의 중요한 응용 프로그램은 ⅔N+1을 기다려야 상대적으로 안전한 최종성을 보장할 수 있습니다. 그러나 이러한 배치 외에도 BSC는 이중 서명 또는 불안정성에 대해 비잔틴 검증자를 처벌하기 위해 Slashing 로직을 도입합니다. 이 Slashing 로직은 악의적인 검증자를 매우 짧은 시간 내에 노출시키고 "클론 공격"을 매우 어렵거나 극도로 비경제적으로 실행하게 만듭니다. 이러한 개선으로, ½*N+1 또는 그보다 적은 블록이 대부분의 거래에 대한 확인으로 충분합니다.

보상

현재 검증자 세트의 모든 BSC 검증자는 BNB에서 수집된 거래 가스 수수료로 보상을 받습니다. BNB는 인플레이션이 없는 토큰이므로, Bitcoin과 이더리움 네트워크가 생성하는 광산 보상과 같은 보상은 없으며, 가스 수수료가 주요 보상입니다. BNB는 다른 용도로도 사용되는 유틸리티 토큰이므로, 위탁자와 검증자는 여전히 BNB를 보유함으로써 다른 혜택을 누릴 수 있습니다.

검증자는 각 블록에서 수집된 거래 수수료로부터 보상을 받습니다. 검증자는 더 많은 스테이킹을 유치하기 위해 위탁자에게 얼마나 많은 보상을 되돌려 줄지 결정할 수 있습니다. 검증자는 동일한 확률로 차례대로 블록을 생성할 것이므로, 장기적으로 모든 안정적인 검증자는 비슷한 크기의 보상을 받게 됩니다. 한편, 각 검증자에 대한 스테이크는 다를 수 있으므로, 더 많은 사용자가 한 검증자에게 신뢰하고 위탁할수록 그들은 잠재적으로 더 적은 보상을 받게 됩니다. 따라서 합리적인 위탁자는 검증자가 여전히 신뢰할 수 있는 한 더 적은 스테이크를 가진 검증자에게 위탁할 경향이 있습니다. 결국 모든 검증자의 스테이크는 변동이 적을 것입니다. 이는 스테이크 집중을 방지하고 일부 다른 네트워크에서 볼 수 있는 "승자가 영원히 승리하는" 문제를 실제로 방지할 것입니다.

가스 수수료의 일부는 크로스체인 통신을 위해 중계자에게도 보상됩니다. 아래 "중계자" 섹션을 참조하십시오.

토큰 경제

BC와 BSC는 BNB와 BEP2 토큰에 대해 동일한 토큰 유니버스를 공유합니다. 이는 다음을 의미합니다:

동일한 토큰은 두 네트워크에서 순환할 수 있으며, 크로스체인 통신 메커니즘을 통해 양방향으로 이동할 수 있습니다.
동일한 토큰의 총 유통량은 두 네트워크에서 관리되어야 하며, 토큰의 총 유효 공급량은 두 BSC와 BC에서의 토큰의 총 유효 공급량의 합계여야 합니다.
토큰은 BSC에서 ERC20과 유사한 형식으로, 또는 BC에서 BEP2로 초기 생성될 수 있으며, 다른 네트워크에서 생성될 수 있습니다. BSC와 BC는 두 형식에서 토큰이 순환할 수 있도록 하고 총 공급량을 확보하며 다양한 사용 사례에서 사용될 수 있도록 함께 작업합니다.

네이티브 토큰

BNB는 이더리움에서 ETH가 운영되는 것과 같은 방식으로 BSC에서 운영되어 BSC와 BC 모두에서 "네이티브 토큰"으로 유지됩니다. 즉, BNB는 Binance Chain 및 Binance DEX에서 대부분의 수수료를 지불하는 데 사용될 뿐만 아니라 다음에도 사용됩니다:

BSC에서 스마트 컨트랙트를 배포하기 위해 "가스"를 지불합니다.
선택된 BSC 검증자에게 스테이크하고 해당 보상을 받습니다.
BC와 BSC 간에 토큰 자산을 이동하는 등의 크로스체인 작업을 수행합니다.

시드 펀드

특정 금액의 BNB는 BC에서 소각되고 BSC의 생성 단계에서 BSC에서 발행될 것입니다. 이 금액은 "시드 펀드"라고 불리며 BSC의 첫 번째 블록 이후에 순환될 것입니다. 이 BNB들은 초기 단계에서 BC에서 BSC로 더 많은 BNB를 이전하기 위해 거래 수수료를 지불하는 데 사용됩니다.

BC에서 BSC로의 BNB 크로스체인 이전은 나중 섹션에서 논의될 것이지만, 일반적으로 BC에서 송금 출발지 주소에서 시스템 제어 주소로 BNB를 잠그고, BSC에서 특수 계약에서 해당 금액을 대상 주소로 잠금 해제하는 것으로 이루어집니다. 반대로 BSC에서 BC로 이전할 때는 BSC의 출발지 주소에서 특수 계약으로 BNB를 잠그고 시스템 주소에서 BC의 대상 주소로 잠긴 금액을 해제합니다. 이 로직은 BC의 네이티브 코드와 BSC의 일련의 스마트 계약과 관련이 있습니다.

기타 토큰

BC는 BEP2 토큰과 곧 도입될 BEP8 토큰을 지원하며, 이는 빠른 거래와 초단위 최종성을 통해 전송 및 거래가 가능한 네이티브 자산입니다. 한편, BSC는 이더리움과 호환되므로 BSC에서 ERC20 토큰을 지원하는 것은 자연스러운 일이며, 여기서는 "BEP2E"라고 불립니다(실제 이름은 향후 BEP에 의해 도입될 예정입니다). BEP2E는 몇 가지 추가 메소드를 추가하여 더 많은 정보를 제공함으로써 "강화될" 수 있습니다. 예를 들어, 토큰 명칭, 소수점 정의 및 두 체인 간의 토큰 바인딩을 결정할 수 있는 소유자 주소입니다. BSC와 BC는 하나의 토큰이 두 형식으로 순환하고 확인된 총 공급량으로 다양한 사용 사례에서 사용될 수 있도록 협력합니다.

토큰 바인딩

BEP2 토큰은 BSC BEP2E 토큰 계약과 연관될 새로운 속성을 호스팅하기 위해 확장될 것이며, 이 과정은 "토큰 바인딩"이라고 불립니다.

토큰 바인딩은 BEP2와 BEP2E가 준비된 후 언제든지 발생할 수 있습니다. BEP2 또는 BEP2E의 토큰 소유자는 바인딩을 원할 때까지 바인딩에 대해 걱정할 필요가 없습니다. 발행자는 BEP2를 먼저 생성하거나 BEP2E를 먼저 생성할 수 있으며, 나중에 바인딩될 수 있습니다. 물론, BEP2와 BEP2E의 모든 발행자에게는 발행 직후 조기에 바인딩을 설정하는 것이 권장됩니다.

BEP2와 BEP2E를 바인딩하는 전형적인 절차는 다음과 같습니다:

BEP2 토큰과 BEP2E 토큰이 각각의 블록체인에 존재하며, 동일한 총 공급량을 가지고 있는지 확인합니다. BEP2E는 일반적인 ERC20보다 3개의 추가 메소드를 가져야 합니다:

a. symbol(): 토큰 심볼을 가져옵니다.
b. decimals(): 토큰의 소수 자릿수를 가져옵니다.
c. owner(): Binder 계약 소유자의 주소를 가져옵니다.
이 값은 BEP2E 계약 생성자에서 초기화되어야 하며, 추후 바인딩 조치가 BEP2E 소유자의 동의를 받았는지 확인할 수 있습니다.
두 블록체인에서 초기 유통량을 결정합니다. 총 공급량이 S이고 BC에서 예상 초기 유통 공급량이 K라면, 발행자는 S-K 토큰을 BC의 시스템 제어 주소에 잠그어야 합니다.
동등하게, K 토큰은 BSC에서 주요 바인딩 기능을 처리하는 특별 계약인 TokenHub에 잠깁니다. BEP2E 토큰의 발행자는 해당 토큰의 K 양을 TokenHub에 잠그고 결과적으로 S-K 토큰이 BSC에서 유통되도록 해야 합니다. 따라서 2개 블록체인에서의 총 유통량은 S로 유지됩니다.
BEP2 토큰의 발행자가 BC에서 바인드 트랜잭션을 보냅니다. 트랜잭션이 적절한 검증 후에 성공적으로 실행되면 다음이 수행됩니다:
a. S-K 토큰을 BC의 시스템 제어 주소로 이전합니다.
b. 중계자가 중계할 대기 중인 크로스체인 바인드 요청 패키지가 생성됩니다.
BSC 중계자는 크로스체인 바인드 요청 패키지를 BSC의 TokenHub로 중계하고, 해당 요청과 정보가 계약에 저장됩니다.
계약 소유자, 그리고 오직 소유자만이 TokenHub 계약의 특별 메소드인 ApproveBind를 실행하여 바인딩 요청을 검증하고 성공으로 표시할 수 있습니다. 이는 다음을 확인합니다:
a. 토큰이 아직 바인드되지 않았습니다.
b. 바인딩이 적절한 심볼, 적절한 총 공급량 및 소수 정보를 위한 것입니다.
c. 두 네트워크에서 적절한 잠금이 이루어졌습니다.
ApproveBind 메소드가 성공하면, TokenHub는 두 토큰이 바인드되었으며 같은 유통을 공유한다고 표시하고, 상태가 BC로 되돌아갑니다. 이 최종 확인 후, BEP2E 계약 주소와 소수 자릿수가 BC의 BEP2 토큰에 새 속성으로 작성되며, 토큰은 두 블록체인 간에 양방향으로 전송될 수 있습니다. ApproveBind가 실패하면, 실패 이벤트도 BC로 전파되어 잠긴 토큰을 해제하고 위의 단계가 나중에 다시 시도될 수 있습니다.

크로스체인 전송 및 통신

크로스체인 통신은 커뮤니티가 이중 체인 구조의 이점을 활용할 수 있게 하는 기본적인 기반입니다:

사용자는 BSC 또는 BC에서 원하는 대로 어떤 토큰화, 금융 제품 및 디지털 자산도 자유롭게 생성할 수 있습니다.
BSC의 항목은 BC의 안정적이고 고성능, 번개처럼 빠르고 친화적인 환경에서 수동적이고 프로그래밍 방식으로 거래되고 유통될 수 있습니다.
사용자는 하나의 UI 및 도구 생태계에서 이러한 작업을 수행할 수 있습니다.

크로스체인 전송

크로스체인 전송은 두 블록체인 간의 주요 통신입니다. 본질적으로 로직은 다음과 같습니다:

전송 출발 블록체인은 소스 소유자 주소에서 시스템 제어 주소/계약으로 토큰 자산의 양을 잠급니다.
전송 도착 블록체인은 시스템 제어 주소/계약에서 토큰 자산의 양을 해제하고 대상 주소로 보냅니다.

크로스체인 전송 패키지 메시지는 BSC 중계자와 BC Oracle 중계자가 다음을 확인할 수 있어야 합니다:

충분한 양의 토큰 자산이 소스 주소에서 제거되어 소스 블록체인의 시스템 제어 주소/계약에 잠겼습니다. 이는 대상 블록체인에서 확인할 수 있습니다.
적절한 양의 토큰 자산이 시스템 제어 주소/계약에서 해제되어 대상 주소에 할당됩니다. 이것이 실패하면, 소스 블록체인에서 확인될 수 있으므로, 잠긴 토큰이 되돌려질 수 있습니다(수수료를 공제할 수 있음).
이 전송 작업이 완료된 후에는 전송이 성공하든 실패하든 두 블록체인 간의 토큰 자산의 총 유통량이 변경되지 않습니다.

크로스체인 통신의 아키텍처는 위에서 설명한 대로입니다. 이러한 두 가지 이질적인 시스템을 수용하기 위해, 통신 처리는 각 방향에서 다르게 처리됩니다.

BC에서 BSC로의 아키텍처

BC는 Tendermint 기반, 즉시 최종성 블록체인입니다. 총 투표권의 최소 ⅔*N+1의 검증자가 체인의 각 블록에 공동 서명합니다. 이를 통해 블록 트랜잭션과 심지어 상태 값까지도 Block Header와 Merkle Proof 검증을 통해 검증할 수 있습니다. 이는 이더리움 커뮤니티에서 집중적으로 논의되고 구현된 "Light-Client Protocol"으로 연구 및 구현되었습니다.

BC에서 BSC로의 통신은 BSC 스마트 계약을 통해 구현된 "온체인 라이트 클라이언트"를 통해 검증됩니다. BC에서 일부 트랜잭션과 상태 변경이 발생하면, 크로스체인 "패키지" 메시지를 생성하고 BSC에 데이터로 제출하는 릴레이어가 됩니다. 라이트 클라이언트는 패키지를 검증하고 검증에 통과하면 트랜잭션을 실행합니다. 검증은 다음 디자인으로 보장됩니다:

BC의 블로킹 상태는 블록 헤더와 사전 커밋을 통해 때때로 BSC의 라이트 클라이언트 계약으로 동기화됩니다.
블록체인 상태의 키-값은 Merkle Proof 및 위의 #1의 정보를 기반으로 검증됩니다.

키-값이 정확하고 신뢰할 수 있는 것으로 확인되면, 라이트 클라이언트 계약은 크로스체인 패키지에 해당하는 작업을 실행합니다. 이러한 패키지의 예는 다음과 같습니다:

바인드: BEP2 토큰과 BEP2E를 바인드합니다.
전송: 바인딩 후 토큰을 전송하면, 이는 BC에서 순환을 감소시키고 (잠금) BSC에서 대상 주소 잔액에 나타납니다.
오류 처리: BSC에서 BC로의 통신에 대한 타임아웃/실패 이벤트를 처리합니다.
BSC의 검증자 세트 업데이트 등입니다.

BSC에서 BC로의 아키텍처

BSC는 스테이크 기반 권한 증명 컨센서스 프로토콜을 사용하며, 포크가 발생할 가능성이 있고 더 많은 블록의 확인이 필요합니다. 한 블록은 하나의 검증자의 서명만을 가지므로, BSC의 데이터를 검증하기 위해 하나의 블록에만 의존하는 것은 쉽지 않습니다.

BC의 검증자 쿼럼의 이점을 최대한 활용하기 위해, 많은 브리지 또는 오라클 블록체인에서 채택된 아이디어와 유사한 아이디어를 사용합니다:

BSC에서 크로스체인 통신 요청은 BSC에서 트랜잭션으로 제출되고 실행됩니다. 트랜잭션 실행은 이벤트를 발생시키며, 이러한 이벤트는 특정 "오라클"에서 관찰되고 패키지될 수 있습니다. 블록 헤더, 해시 및 Merkle Proof 대신, 이러한 유형의 "오라클" 패키지는 전송의 발신자, 수신자 및 금액과 같은 크로스체인 정보를 직접 포함합니다.
오라클의 보안을 확보하기 위해, BC의 검증자는 "오라클 릴레이어"라고 불리는 또 다른 쿼럼을 형성해야 합니다. 각 검증자는 전용 프로세스로 오라클 릴레이어를 운영해야 하며, 이 오라클 릴레이어는 동일한 검증자 키를 사용하여 BC에 크로스체인 통신 패키지를 제출하고 투표합니다. ⅔*N+1 이상의 오라클 릴레이어의 투표권을 가진 패키지는 동일한 쿼럼의 검증자의 투표권으로 서명된 블록만큼 안전합니다.

BC의 동일한 검증자 쿼럼을 사용함으로써, BC에 지속적인 블록 업데이트를 저장하고 라이트 클라이언트 코드를 절약할 수 있습니다. 이러한 오라클은 또한 오라클 ID와 유형을 가지고 있어, 순차적 처리와 적절한 오류 처리를 보장합니다.

타임아웃 및 오류 처리

크로스체인 통신이 실패하는 시나리오가 있습니다. 예를 들어, BSC에서 실행할 수 없는 코딩 버그로 인해 릴레이된 패키지가 실행되지 않는 경우입니다. 이러한 시나리오에서는 타임아웃 및 오류 처리 로직을 사용합니다.

인식 가능한 사용자 및 시스템 오류 또는 예상 가능한 예외의 경우, 두 네트워크는 스스로 치유해야 합니다. 예를 들어, BC에서 BSC로의 전송이 실패하면 BSC는 실패 이벤트를 발행하고 오라클 릴레이어가 BC에서 환불을 실행합니다; BSC에서 BC로의 전송이 실패하면, BC는 릴레이어가 잠긴 자금을 해제하기 위해 환불 패키지를 발행합니다.

그러나 예상치 못한 오류나 예외는 크로스체인 통신의 어떤 단계에서든 발생할 수 있습니다. 이 경우 릴레이어와 오라클 릴레이어는 해당 크로스체인 채널이 특정 시퀀스에서 멈춰 있다는 것을 발견하게 됩니다. 타임아웃 기간 후, 릴레이어와 오라클 릴레이어는 "SkipSequence" 트랜잭션을 요청할 수 있으며, 멈춰 있는 시퀀스는 "실행 불가"로 표시됩니다. 해당 경고가 발생하면 커뮤니티는 이 시나리오를 어떻게 처리할지 논의해야 합니다. 예를 들어, 검증자의 후원을 통해 환불을 진행하거나 다음 네트워크 업그레이드 동안 오류로 잠긴 자금을 정리할 수 있습니다.

크로스체인 사용자 경험

이상적으로, 사용자는 하나의 단일 체인을 사용하는 것처럼 두 개의 병렬 체인을 사용하기를 기대합니다. 이를 위해 크로스체인 통신에 더 많은 집계된 트랜잭션 유형을 추가해야 합니다. 이는 큰 복잡성, 긴밀한 결합 및 유지 관리 부담을 추가할 것입니다. 여기서 BC와 BSC는 초기 출시에서 가치 흐름을 가능하게 하는 기본 작업만을 구현하고 대부분의 사용자 경험 작업을 클라이언트 측 UI, 예를 들어 지갑과 같은 것에 맡깁니다. 예를 들어, 훌륭한 지갑은 사용자가 BSC에서 BC의 DEX 주문서로 토큰을 직접 판매할 수 있게 하여 안전한 방식으로 할 수 있습니다.

크로스체인 계약 이벤트

크로스체인 계약 이벤트(CCCE)는 스마트 계약이 계약 코드를 통해 직접 크로스체인 트랜잭션을 트리거할 수 있도록 설계되었습니다. 이는 가능하게 되었는데, 그 이유는:

일반 스마트 계약이 호출할 수 있는 작업을 제공하기 위해 표준 시스템 계약을 제공할 수 있습니다.
표준 계약에 의해 방출되는 표준 이벤트들.
오라클 릴레이어가 표준 이벤트를 캡처하고 해당 크로스체인 작업을 트리거할 수 있습니다.
BC에서 계약 주소를 생성하고 BSC의 계약에 의해 접근할 수 있는 전용, 코드 관리 주소(계정)가 생성됩니다.

여러 표준 작업이 구현되었습니다:

BSC에서 BC로의 전송: 이는 일반 BSC에서 BC로의 전송과 동일한 방식으로 구현되지만, 표준 계약을 통해 트리거됩니다. 자금은 BC의 어떤 주소로도 전송될 수 있으며, 전송 원점 계약의 해당 CAoB(Contract Address on BC)를 포함할 수 있습니다.
BC에서의 전송: 이는 특별한 크로스체인 전송으로 구현되며, 실제 전송은 CAoB에서 다른 주소(다른 CAoB 포함)로 이루어집니다.
BC에서 BSC로의 전송: 이는 두 단계의 크로스체인 커뮤니케이션으로 구현됩니다. 첫 번째는 BSC 계약에 의해 트리거되고 BC로 전파되며, 두 번째 단계에서는 BC가 일반 BC에서 BSC로의 크로스체인 전송을 시작합니다.
즉시 또는 취소 거래(IoC Trade Out): 자산을 BC로 이전하는 주된 목표는 거래입니다. 이 이벤트는 CAoB의 일정 금액의 자산을 가능한 한 많이 다른 자산으로 거래하도록 지시하고, 모든 결과(원본 자산과 거래된 목표 토큰)를 BSC로 다시 전송하도록 합니다.

스테이킹 및 거버넌스

스테이크 기반 권한 증명은 분산화와 커뮤니티 참여를 가져옵니다. 이의 핵심 로직은 아래와 같습니다:

토큰 홀더들은 검증자 또는 검증자 후보에게 자신의 토큰을 "보증"으로 위임할 수 있습니다.
모든 검증자 후보는 그들에게 위임된 토큰의 수에 따라 순위가 매겨지며, 상위 후보들이 실제 검증자가 됩니다.
검증자는 차단 보상의 일부를 그들의 위탁자와 공유할 수 있습니다.
검증자는 이중 서명과/또는 불안정성과 같은 나쁜 행동에 대해 "슬래싱"으로 불리는 처벌을 받을 수 있으며, 이러한 손실은 그들의 위탁자와도 공유됩니다.
검증자와 위탁자에게는 "언바운딩 기간"이 있어 시스템이 나쁜 행동을 적발했을 때 토큰이 보증된 상태로 유지되도록 하며, 이 기간 동안 책임이 있는 자는 처벌을 받습니다.

BC에서 스테이킹

이상적으로는 스테이킹 및 보상 로직이 블록체인에 내장되어 블로킹이 발생함에 따라 자동으로 실행되어야 합니다. Cosmos Hub는 Binance Chain과 동일한 Tendermint 컨센서스와 라이브러리를 공유하며, 이 방식으로 작동합니다.

BC는 설계 단계부터 스테이킹 로직을 활성화하기 위한 준비를 해왔습니다. 반면에, BSC는 가능한 한 이더리움과 호환성을 유지하고자 하며, 특히 이더리움 자체가 잠시 후 다른 증명 방식의 컨센서스 프로토콜로 이동할 가능성이 있을 때 이는 큰 도전과 노력을 필요로 합니다. 호환성을 유지하고 BC의 좋은 기반을 활용하기 위해 BSC의 스테이킹 로직은 BC에서 구현됩니다:

스테이킹 토큰은 어쨌든 두 블록체인에서 네이티브 토큰인 BNB입니다.
BSC의 스테이킹, 즉 토큰 결속 및 위임 행위 및 기록은 BC에서 발생합니다.
BSC 검증자 세트는 BC에서 BSC로 구축된 스테이킹 모듈을 통해 결정되며, 매일 UTC 00:00에 크로스체인 커뮤니케이션을 통해 전파됩니다.
보상 분배는 BC에서 매일 UTC 00:00에 발생합니다.

보상

검증자 업데이트와 보상 분배는 모두 매일 UTC 00:00경에 이루어집니다. 이는 빈번한 스테이킹 업데이트와 블록 보상 분배의 비용을 절약하기 위함입니다. 이 비용은 상당할 수 있으며, 블록 보상은 BSC에서 수집되어 BC의 BSC 검증자와 위탁자에게 분배됩니다. (BC 블로킹 수수료는 BC 검증자에게만 보상으로 남습니다.)

공정한 분배를 보장하기 위해 일부러 지연이 도입됩니다:

블록 보상은 즉시 검증자에게 전송되지 않고 계약에 계산되어 축적됩니다.
BSC로의 검증자 세트 업데이트를 수신하면 몇 가지 크로스체인 전송을 트리거하여 해당 검증자의 보호 주소로 보상을 전송합니다. 보호 주소는 시스템이 소유하므로 위탁자에게 약속된 분배가 이루어질 때까지 보상을 사용할 수 없습니다.

슬래싱

슬래싱은 온체인 거버넌스의 일부로, 악의적이거나 부정적인 행동이 처벌되도록 보장합니다. BSC에서 슬래싱은 누구나 제출할 수 있습니다. 트랜잭션 제출은 슬래시 증거와 비용이 필요하지만, 성공적인 경우보다 훨씬 큰 보상을 가져옵니다.

지금까지 두 가지 슬래시 가능한 사례가 있습니다.

더블 사인: 한 검증자가 동일한 높이와 부모 블록으로 두 개 이상의 블록에 서명하는 것은 심각한 오작동이며, 대부분 고의적인 범죄일 가능성이 높습니다. 참조 프로토콜 구현은 이미 이를 방지하기 위한 로직을 가지고 있어야 하므로, 악의적인 코드만이 이를 트리거할 수 있습니다. 더블 사인이 발생하면, 해당 검증자는 즉시 BSC 검증자 세트에서 제거되어야 합니다.

누구나 BSC의 더블 사인 증거와 함께 BC에서 슬래싱 요청을 제출할 수 있으며, 이는 두 블록 헤더를 포함해야 합니다. BC가 증거를 검증하고 유효하다고 확인하면 다음이 수행됩니다:

검증자는 즉시 BSC 검증자 세트에서 제거됩니다.
검증자에 대한 스테이크는 사전 정의된 금액만큼 감소됩니다.
감소된 BNB의 일부는 제출자의 주소로 할당되며, 이는 제출 비용보다 훨씬 큰 보상입니다.
나머지 감소된 BNB는 다른 검증자의 보호 주소로 할당되며, 이는 모든 위탁자에게 블록 보상과 같은 방식으로 분배됩니다.

불안정성

BSC의 생명력은 스테이크 기반 권한 증명 검증자 세트의 모든 구성원이 차례가 돌아왔을 때 적시에 블록을 생성할 수 있는 능력에 달려 있습니다. 검증자는 하드웨어, 소프트웨어, 구성 또는 네트워크의 문제로 인해 차례를 놓칠 수 있습니다. 이러한 운영의 불안정성은 네트워크 성능을 저하시키고 시스템에 더 많은 비결정성을 도입합니다.

이에 대한 내부 스마트 계약은 각 검증자의 놓친 블로킹 메트릭을 기록할 책임이 있습니다. 이 메트릭이 사전 정의된 임계값을 초과하면, 해당 검증자의 블로킹 보상은 BC로 전달되어 분배되지 않고 다른 더 나은 검증자와 공유됩니다. 이 방식으로, 부적절하게 운영되는 검증자는 그들의 위탁자가 더 적거나 보상을 받지 못함에 따라 점차 검증자 세트에서 퇴출될 것입니다. 메트릭이 또 다른 높은 수준의 임계값을 계속 초과하는 경우, 검증자는 회전에서 제외되고 이는 BC에서 또 다른 슬래싱이 발생하는 곳으로 전파됩니다.

매개변수 거버넌스

BSC의 많은 시스템 매개변수가 시스템의 행동을 제어합니다. 예를 들면, 슬래싱 임계값과 금액, 크로스체인 전송 수수료 등이 있습니다. 이러한 모든 매개변수는 BSC 검증자 세트가 그들의 스테이킹을 기반으로 한 제안-투표 과정을 통해 결정됩니다. 이 과정은 BC에서 진행되며, 새 매개변수 값은 크로스체인 커뮤니케이션을 통해 해당 시스템 계약에 의해 선택됩니다.

릴레이어

릴레이어는 두 블록체인 간의 크로스체인 커뮤니케이션 패키지를 제출하는 책임이 있습니다. 이질적인 병렬 체인 구조로 인해, 두 가지 유형의 릴레이어가 생성됩니다.

BSC 릴레이어

BC에서 BSC로의 커뮤니케이션을 위한 릴레이어는 "BSC 릴레이어" 또는 간단히 "릴레이어"라고 불립니다. 릴레이어는 독립적인 프로세스로, 누구나 어디에서나 운영할 수 있습니다. 단, 릴레이어는 BSC에 등록하고 일정 금액의 BNB를 보증금으로 예치해야 합니다. BSC에 등록된 릴레이어만이 BSC에서 릴레이 요청을 받아들일 수 있습니다.

오라클 릴레이어

BSC에서 BC로의 커뮤니케이션을 위한 릴레이어는 "오라클" 모델을 사용하며 "오라클 릴레이어"라고 불립니다. 검증자 세트의 구성원만이 오라클 릴레이어를 운영할 수 있으며, 각 오라클 릴레이어는 BSC 상태 변경을 감시합니다. 크로스체인 커뮤니케이션 패키지를 캡처하면, 이를 BC에 제출하고 투표합니다. ⅔*N+1 이상의 오라클 릴레이어의 투표를 받은 패키지는 실행됩니다.

오라클 릴레이어는 BSC에서 최종성을 확인한 후 BC에 크로스체인 커뮤니케이션 패키지를 제출하고 투표해야 합니다. 크로스체인 수수료는 BC의 일반 블로킹 보상과 함께 BC 검증자에게 분배됩니다.

이 오라클 유형의 릴레이는 모든 검증자의 지원을 필요로 하며, 모든 투표가 블록체인에 기록되므로 오라클 릴레이어의 성능을 평가하는 메트릭 시스템을 가질 수 있습니다. 성능이 가장 낮은 릴레이어는 향후 도입될 수 있는 또 다른 슬래싱 논리를 통해 보상이 회수될 수 있습니다.

전망

Binance Chain에 대해 결론을 내리기는 어렵습니다. 왜냐하면 그것은 계속해서 진화하고 있기 때문입니다. 이중 체인 전략은 사용자가 한쪽에서는 빠른 전송과 거래의 이점을, 다른 한쪽에서는 유연하고 확장 가능한 프로그래밍의 이점을 활용할 수 있도록 하지만, 이것은 Binance Chain의 개발 중 한 과정일 뿐입니다. 앞으로 커뮤니티를 더 잘 지원하기 위해 다음과 같은 주제를 조사할 것입니다:

다양한 디지털 자산 모델을 다양한 비즈니스 사용 사례에 추가합니다.
Binance DEX에서 BSC로, 특히 DEX 시장 데이터와 같은 더 많은 데이터 피드를 커뮤니케이션할 수 있도록 합니다.
이더리움의 추가 업그레이드를 포함하여 이더리움 및 기타 블록체인과의 인터페이스 및 호환성을 제공합니다.
지갑을 관리하고 블록체인을 더 편리하게 사용할 수 있도록 클라이언트 측 경험을 개선합니다.

이 모든 것은 Binance Chain과 Binance Smart Chain이 유기적으로 연결되어 다양한 기능을 지원하고 전반적인 블록체인 생태계의 발전에 기여할 수 있도록 하는 것을 목표로 합니다. 우리의 미래 계획과 비전은 계속해서 우리 커뮤니티의 요구와 기술 발전에 따라 조정될 것입니다.

Binance Chain의 이중 체인 구조는 비단 거래 속도와 프로그래밍 가능성의 이점만을 제공하는 것이 아니라, 그 이상의 가치를 창출하려는 우리의 야심을 반영합니다. 이러한 구조를 통해 사용자와 개발자는 향후 블록체인 기술의 발전에 적극적으로 참여하고 새로운 솔루션을 탐색할 수 있는 더 많은 기회를 가질 것입니다.

Binance Smart Chain의 성공적인 배치와 운영은 향후 몇 년 동안 우리 생태계를 크게 확장하는 데 중요한 역할을 할 것입니다. 우리는 이 기술이 전 세계의 다양한 사용자와 개발자에게 실질적인 혜택을 제공하고, 더 많은 사람들이 블록체인 기술의 잠재력을 실현하도록 돕기를 기대합니다.

인생 1회차 성장기

[메인넷 공부] BNB 체인 백서 한글번역