diff --git "a/BNB\346\231\272\350\203\275\351\223\276.md" "b/BNB\346\231\272\350\203\275\351\223\276.md" index b9ddc68..e545ab9 100644 --- "a/BNB\346\231\272\350\203\275\351\223\276.md" +++ "b/BNB\346\231\272\350\203\275\351\223\276.md" @@ -1,365 +1,197 @@ -# 币安智能链 +# BNB 智能链 -> 支持智能合约的平行币安链 - - - -0.1 版本 - -2020/04/17 +## 目录 +- [BNB 智能链](#BNB-智能链) - [动机](#动机) +- [BNB 链的演进](#BNB链的演进) - [设计原则](#设计原则) -- [共识与验证者的人数](#共识与验证者的人数) - - [基于权益的权威证明 (Proof Of Staked Authority)](#基于权益的权威证明-proof-of-staked-authority) - - [验证人节点法定人数](#验证人节点法定人数) - - [安全与最终性](#安全与最终性) - - [收益](#收益) -- [代币经济学](#代币经济学) +- [代币经济](#代币经济) - [原生代币](#原生代币) - - [其他代币](#其他代币) -- [跨链转账与通信](#跨链转账与通信) - - [跨链转账](#跨链转账) - - [BC到BSC架构](#bc到bsc架构) - - [BSC到BC 架构](#bsc到bc-架构) - - [超时与错误处理](#超时与错误处理) - - [跨链用户体验](#跨链用户体验) - - [跨链合约事件](#跨链合约事件) -- [权益质押与链上治理](#权益质押与链上治理) - - [BC权益质押](#bc权益质押) - - [奖励](#奖励) - - [罚息](#罚息) -- [中继器](#中继器) - - [BSC中继器](#bsc中继器) - - [激励](#激励) - - [Oracle中继器](#oracle中继器) + - [种子基金](#种子基金) + - [实时销毁](#实时销毁) +- [共识和验证人法定人数](#共识和验证人法定人数) + - [质押权威证明](#质押权威证明) + - [验证人集合](#验证人集合) + - [验证人选举](#验证人选举) +- [系统合约](#系统合约) +- [奖励分配](#奖励分配) +- [安全性和最终性](#安全性和最终性) +- [治理](#治理) +- [惩罚和处罚](#惩罚和处罚) + - [双重签名](#双重签名) + - [恶意快速最终性投票](#恶意快速最终性投票) + - [不可用性](#不可用性) - [展望](#展望) ## 动机 -币安链于2019 年4月推出主网后，展示了其高速、高吞吐的设计。其主要关注点——原生去中心化应用程序（“dApp”）币安链 DEX（去中心化交易所），经受了在短时间内处理数百万交易量的考验，展示了它的交易引擎的低延迟撮合能力。 - -灵活性及可用性往往和性能是熊掌与鱼不能兼得。当关注点集中在如何提供一个方便的数字资产发行和交易场所上时，这种设计在某种程度上也带来了限制。 社区呼声最高的一直是最希望看到币安链增加可编程扩展功能，或者直白点说，就是[智能合约](https://en.wikipedia.org/wiki/Smart_contract)和虚拟机功能。由于当前币安链的有限功能，数字资产发行者和所有者想要为其资产添加新的去中心化的特性或引入任何形式的社区管理及社区活动时都颇为头痛。 - -尽管在币安链中添加智能合约功能的期望很高，但这却是个“艰难的决定”。 智能合约的执行可能会减慢DEX的运行速度，并为资产交易添加不确定性因素。即便可以容忍这种妥协，最容易想到的方案可能是基于当前底层的Tendermint共识协议和币安链的主要 RPC接口实现一个虚拟机，但是这种方案会增加现有 dApp 社区的学习成本，不会是一个受欢迎解决方案。 - -这里我们提出了币安链的并行区块链的概念，以保持原生DEX的高性能，同时友好地支持智能合约功能。 - -## 设计原则 - -在币安链生态系统中构建两个并行区块链之后，两个区块链将各自运行以提供不同的服务。 新的并行链将被称为“币安智能链”（以下部分简称为**“BSC”**），而现有的主网仍然称为**“币安链”**（以下部分简称为**“BC”**）。 - -BSC的设计遵循以下原则： - -1. **独立区块链**： 从技术上讲，BSC 是一个独立的区块链，而不是Layer 2解决方案。 大多数 BSC 的基础技术和业务功能应该是独立的，这样即使BC短时间停止，BSC也可以运行良好。 - -2. **以太坊兼容**： 第一个实用的、被广泛使用的智能合约平台是以太坊 。为了对接相对成熟的应用和社区，BSC 选择与现有的以太坊主网兼容。 这意味着大多数**dApp**、生态系统组件和工具将与BSC兼容，不需要修改或只需要很小的更改；BSC 节点仅需要类似，或稍高的硬件规范和操作技能就能运作。这一实现应为 BSC 和以太坊未来的版本继续兼容提供空间。 - -3. **基于权益质押的共识和链上管理的**：基于权益质押（PoS）的共识更环保，给社区治理提供更灵活的选择。可以预期的是，这种共识会比PoW共识有更好的性能，即出块时间短，交易处理容量高。 - -4. **原生跨链通信**： BC 和 BSC 都将原生支持两个区块链之间的跨链通信。 通信协议应该是双向的、去中心化的、无需信任第三方的。 它将专注于在 BC 和 BSC 之间转移数字资产，即 BEP2代币，以及后来引入的其他 BEP代币。 该协议应该不会过于关注存储在区块链其他信息，只有少数情况例外。 - -## 共识与验证者的人数 - -基于以上设计原则，BSC的共识协议是为了实现以下目标： -1. 出块时间应该比以太坊时间短，例如 5 秒甚至更短。 -2. 只需要等待有限的时间就能最终确认交易，例如大约 1 分钟或更短。 -3. 没有通货膨胀，区块链的收益来自手续费，手续费以BNB的形式支付。 -4. 尽可能与以太坊兼容。 -5. 配备了基于权益质押的链上治理机制。 - -### 基于权益的权威证明 (Proof Of Staked Authority) - -尽管工作量证明（PoW）已被证明为实现去中心化网络的实用方案，但它对环境并不友好，而且还需要大量参与者来维护网络安全。 - -以太坊及一些其他网络，如 MATIC Bor、TOMOChain、GoChain、xDAI在不同的场景中使用权威证明（PoA）或其变体，包括测试网络和主网。PoA 为 51%的攻击提供了防御，更有效的防止一部分拜占庭节点作恶。 选用PoA作为底层共识是理想的选项之一。 +自2019年4月主网社区启动以来，信标链展示了其高速和大吞吐量的设计。信标链的主要焦点是支持一个原生的、低延迟、高性能的去中心化交易所。其中最受欢迎的功能之一是可编程的可扩展性，特别是智能合约和虚拟机功能的实现。为了满足这一需求，我们提出了与信标链并行运行的BNB智能链，以促进一个用户友好的智能合约环境。 -同时，PoA 协议因不如PoW去中心化而被批评，因为验证人，即轮流生成块的节点，拥有极大的权力，并且容易产生腐败和遭受安全攻击。 其他区块链, 如 EOS, 引入了不同类型的委托权益证明（DPoS），允许代币持有者投票选举验证人节点。 它让网络更加去中心化，有利于社区管理。 +BNB智能链（BSC）是一个与EVM兼容的区块链，旨在为BNB链生态系统带来可编程性和互操作性。作为更广泛的BNB链的一部分，BSC旨在为去中心化应用（dApps）和数字资产提供高吞吐量、低延迟和低成本的环境。本白皮书概述了BSC的架构、机制和演进历程。虽然已经过去几年，我们仍然保留这份文件，因为它继续作为一个有用的参考，并准确地代表BNB智能链。 -受以上启发，BSC 将 DPoS 和 PoA 结合以达成共识，采用的方案为： +## BNB链的演进 -1. 区块是由有限数量的验证人生成的 -2. 验证人轮流以 PoA 方式生成区块，类似于以太坊的Clique共识引擎 -3. 验证人集合是基于权益质押的链上治理选出和淘汰 +- **初始启动和信标链。** 信标链于2019年4月启动，旨在支持BNB DEX，具备快速交易和大吞吐量的特性。然而，其缺乏可编程性和智能合约功能对开发者和用户造成了限制。 -### 验证人节点法定人数 +- **BNB智能链的引入。** 为了解决这些限制，BNB智能链于2020年引入，利用并行区块链架构支持智能合约，同时保持DEX的高性能。 -在网络启动的创世块阶段，一些受信任的节点将作为初始验证人集合运行。开始出块后，任何人都可以作为候选人参与竞选验证人。 权益质押状态决定前 21 个权益质押最多的节点成为下一个验证人集合，这样的选举和淘汰每 24 小时进行一次。 +- **BNB链融合。** 2023年11月，BNB链融合提案（[BEP-333](https://github.com/binance-chain/BEPs/blob/master/BEP333.md)）标志着一个重大转变。这个提案概述了信标链的终结，将其功能与BSC合并，创建一个统一的高性能区块链网络。这次融合旨在简化操作，增强安全性，并简化BSC上的用户体验。 -**BNB 是BSC权益质押的通证。** +- **opBNB。** 于2023年推出，opBNB是一个基于Optimism OP Stack的以太坊虚拟机（EVM）兼容的Layer 2链。它旨在通过提供更低的gas费用和高性能区块链技术来革新区块链行业。 -为了保持与以太坊共识协议（包括即将到来的升级）的兼容性，BSC 选择依赖BC 进行权益质押管理（请参阅下面的“权益质押与管理”部分）。 在 BC上有一个专用于BSC权益质押的模块。 它将接受BNB 持有者的BSC权益质押，并计算出权益质押最多节点集。 每次UTC 零时，BC 都会发出一条可校验的 `“ValidatorSetUpdate”`跨链消息，通知 BSC 更新其验证人集合。 +- **BNB Greenfield。** Greenfield是一个新颖的去中心化数据存储网络，与BNB智能链（BSC）有原生桥接，管理用户权限、存储桶创建和文件删除，从而改变用户与其数据交互的方式。 -在生成新的区块前，现有的BSC验证人定期检查是否有`“ValidatorSetUpdate”`消息转发到BSC 。 如果有，它们将在一段高度后（即预定义的区块间隔）之后更新验证人集合。 例如，如果 BSC 每 5 秒生成一个区块且检查周期是 240 个区块，那么当前的验证人集合将在 1200 秒（20 分钟）内检查并更新下一周期的验证人集。 +BNB链是一个不断发展的生态系统，BSC是其核心。作为一个关键的金融系统，BSC承载着最多的加密资产价值。它还作为opBNB和其他Layer 2解决方案的结算和数据可用性层，确保layer2的安全性。此外，BSC作为Greenfield的智能合约编程平台，促进Greenfield内的数据交换和流通。 -### 安全与最终性 +BSC从最初的双链架构（其中质押、验证和治理委托给信标链）发展到现在，经历了显著的演变。在BNB链融合之后，BSC经历了实质性的架构变更，最终成为一个完全独立的区块链。 -考虑到有超过一半的 ½\*N+1 验证人是诚实可信的，基于 PoA 的网络通常可以安全、正常地工作。 然而在某些情况下，拜占庭验证人仍然可能设法攻击网络， 比如通过“克隆攻击”的方式。 为了保证具BSC有与BC一样高的安全性，我们鼓励BSC 用户等待到接收的区块被超过⅔\*N+1 不同的验证人所确认。 通过这种方式，BSC 可以实现与 BC 相似的安全级别，可以容忍少于1/3 \*N 的拜占庭验证人。 +## 设计原则 -对于 21 个验证人，如果区块时间为 5 秒，那么 ⅔\* N + 1 个不同的验证人确认将需要（2/3\*21 + 1）\*5 =75秒的时间。BSC 的任何重要应用程序可能都必须等待⅔*N + 1，以确保相对安全的最终结果。 然而，除了这样的安排，BSC 还引入了惩罚机制来惩罚拜占庭验证人的双重签名或不稳定性，这将在后面的“权益质押和管理”部分中做出介绍。 这种惩罚机制将在很短的时间内暴露恶意验证人，并使 “克隆攻击”非常难以执行或即使执行了也非常不划算。 通过这种惩罚机制，½\*N + 1 甚至更少的区块就足够满足大部分交易最终性了。 +以下是BSC的设计原则： -### 收益 +1. **独立区块链：** 从技术上讲，BSC是一个独立的区块链，而不是一个layer-2解决方案。BSC的大多数基本技术和业务功能应该是自驱动的。 -当前验证人集合中的所有 BSC 验证人都将从以BNB 支付的手续费中获得收益。由于 BNB 不是一个会通胀的通证，因此不会像比特币和以太坊网络那样产生挖矿收益，手续费是验证人的主要收益。 由于BNB 也是其他应用的实用型通证，委托人和验证人仍将获得持有BNB 的其他好处。 +2. **以太坊兼容性：** 以太坊是第一个实用且广泛使用的智能合约平台。为了利用相对成熟的应用和社区，BSC选择与现有的以太坊主网兼容。这意味着大多数dApps、生态系统组件和工具无需或只需最小的更改就能与BSC一起工作；BSC节点将需要类似（或稍高）的硬件规格和技能来运行和操作。BSC的实现具备跟上以太坊的进一步升级的能力。 -验证人的收益是从每个区块的交易中收取的手续费获得的。验证人可以决定向质押了BNB 的委托人分享多少收益，以吸引更多的质押投资。 每个验证人将以相同的概率轮流生成区块（如果它们保持 100%在线），因此，从长远来看，所有稳定的验证人都可能获得类似规模的收益。 同时，每个验证人的质押资产大小可能是不同的，因此，这带来了一种与直觉相反的情况，即更多的用户信任并委托质押于同一个验证人，他们可能获得更少收益。因此，只要验证人仍然是可信的（不受信任的验证人可能带来极大的风险），理性的委托人就会倾向于委派抵押数量较低的验证人。 最终，所有验证人的区别都会更小。这实际上将防止其他网络上出现的质押集中和“赢家永远赢”的问题。 +3. **涉及质押的共识和治理：** 基于质押的共识更加环保，并为社区治理留下更灵活的选择。预期这种共识应能实现比[工作量证明](https://en.wikipedia.org/wiki/Proof_of_work)区块链系统更好的网络性能，即更快的出块时间和更高的交易容量。 -手续费的一部分也将奖励给跨链通信的中继器。 请参考下面的“中继器”部分。 +4. **快速出块时间和快速最终性：** BSC将实施快速最终性机制，允许在正常情况下在两个区块确认内完成区块最终性。这一特性，结合BSC 3秒的快速出块时间，提供了近乎即时的交易最终性和良好的用户体验。 -## 代币经济学 +## 代币经济 -BNB 和 BEP2代币可以在BC和BSC上同时流通。由此定义了： +BSC、opBNB和Greenfield共享BNB这一统一代币。这定义了： -1. 同一代币可以在两个网络上流通，并且通过跨链通信机制双向地在它们之间流通。 -2. 同一代币的总发行量由两个网络共同决定，即代币的总有效供应量应该是代币在BSC和BC上的发行量的总和。 -3. 代币可以最初在BSC上创建，格式类似于 ERC20，然后在BC上创建为BEP2，相反的顺序创建也可以。 在这两个网络上都有原生方式来连接这两个网络，并确保代币的总发行量一致。 +1. BNB可以在所有网络上流通，并通过跨链通信机制流动。 +2. BNB的总流通量应在三个网络中管理，即BNB的总有效供应量应是所有网络中代币总有效供应量的总和。 ### 原生代币 -BNB在BSC上运行的方式与ETH 在 以太坊 上运行的方式相同，因此它是BSC和 BC的“原生代币”。这意味着BNB 除了可以在币安链和币安 DEX上被用来支付大部分手续费用之外，BNB 也将用于： - -1.支付在 BSC上部署智能合约的手续费 -2.对选定的 BSC 验证人进行权益质押，并获得相应的奖励 -3.执行跨链操作，例如跨 BC 和 BSC 转账代币资产 - -**启动基金** - -在启动阶段，一定量的BNB将在 BC上销毁，然后转移到 BSC 上。 这个数额被称为 “启动基金”，它将被记录在BSC的第一个区块中，它将被转移到初始 BC-to-BSC 中继器账户（在后面的章节中描述）和初始验证人集合账户上。这些BNB 用于在早期阶段支付交易费用，通过跨链机制将更多的 BNB 从BC 转移到BSC 。 - -BNB 跨链转账将在后面的小节中讨论，但对于BC到BSC转账，通常是将 BC上的 BNB 从转账的源地址锁定到一个系统控制的地址，并将相应数量的 BNB 从特殊合约解锁到 BSC 上转账的目标地址，或者相反，当从 BSC 转换到BC 时，是将BNB 从BSC 上的源地址锁定到一个特殊合约中，并将 BC 上的锁定的BNB从系统地址释放到目标地址。这种逻辑由 BC 上的代码和 BSC 上的一系列智能合约实现。 - -### 其他代币 - -BC 支持 BEP2代币和即将投入使用的 BEP8 代币，它们是原生资产，可快速交易并确认，可以流通，上币后可以在DEX上交易。 同时，由于 BSC 是 以太坊兼容的，在 BSC 上支持 ERC20合约被称为 “BEP2E”（未来可以通过BEP修改命名，同时也可能支持 BEP8）。BEP2E通过添加更多的方法来“增强”已有协议，这些方法可以公开更多的信息，比如代币单位、精度。代币所有者能够决定跨链代币绑定地址。 BSC 和 BC 共同确保一个代币在不同的用例中的总流通量不变。 - -**代币绑定** - -BEP2代币将增加一个新的属性用来记录该代币所对应的BSC BEP2E合约（称为“绑定器”），而这个过程被称为“代币绑定”。 - -代币绑定可以在BEP2 和BEP2E部署好之后的任何时候进行。BEP2或BEP2E的代币所有者在不同的链上使用代币之前，不需要担心绑定。 发行者可以先创建 BEP2，也可以先创建 BEP2E，它们可以在稍后的时间进行绑定。 当然，我们鼓励 BEP2 和 BEP2E 的所有发行者在发行后尽早建立绑定。 - -绑定BEP2 和BEP2E的典型过程如下： - -1. 确保在两条链上的 BEP2 代币和 BEP2E代币具有相同的总供应量。与更典型的ERC20合约 相比，BEP2E必须添加以下有3 种函数： - -- symbol()： 获取代币符号 -- decimals()： 获取代币十进制小数位数 -- getOwner()： 获取绑定合约所有者的地址。这个值应该在 BEP2E合约构造函数中初始化，以便绑定操作可以进一步验证绑定消息是否得到来自 BEP2E的发行者。 - -2. 确定两个区块链的初始发行量。假设总供应量为*S*，并且 BC 上的预期初始循环供应量为 *K*，那么所有者应该将 S-K 个代币锁定到 BC上的系统控制地址。 - -3. 同样，*K*个代币被锁定在BSC上的特殊合约中，由一个叫做TokenHub的合约控制绑定相关功能。BEP2E代币的发行者应该将该代币的*K*个锁定到TokenHub，从而使*S- K*个*代币在BSC上流通。因此，两个区块链之间的总流通量仍然是*S*。 - -4. BEP2 代币的发行者在BC 上发送绑定交易。经过适当的验证后，一旦交易成功执行： - -* 它将 *S-K* 个代币转账到BC 上的系统控制地址。 - -* 将创建一个跨链绑定请求包，等待中继传递消息。 +BNB将在BSC上运行，就像ETH在以太坊上运行一样，因此它仍然是BSC的"原生代币"。这意味着BNB将用于： -5. BSC 中继将把跨链绑定请求包中继到 BSC 上的 TokenHub 中，相应的请求和信息将存储在合约中。 +1. 支付在BSC上部署智能合约的"费用"。 +2. 在选定的BSC验证人上进行质押，并获得相应的奖励。 +3. 执行跨链操作，如在BSC、opBNB和Greenfield之间转移代币资产。 -6. 合约所有者（且只有该所有者）可以运行TokenHub合约的特殊方法ApproveBind来验证绑定请求，以将其标记为成功状态。它将验证： +### 种子基金 -- 代币未被绑定； -- 绑定具备正确的代币名称，并具有正确的总供应量和位数信息； -- 在两个网络上正确完成锁定； +在BSC的创世阶段，一定数量的BNB将在信标链上销毁，并在BSC上铸造。这个数量被称为"种子基金"，在第一个区块后在BSC上流通以分配给在创世时引入的初始验证人集合。 -7. 一旦`ApproveBind`方法成功，`TokenHub`将标记这两种代币是绑定的，并且在 BSC 上共享同一总流通量，并且状态将传回 BC。在经过BC的最终确认后，BEP2E合约地址和小数点位数将作为一个新属性写入BEP2代币上，代币就可以双向地在两个区块链之间进行转账。 如果 ApproveBind 失败，则故障事件也将传输回BC 以释放锁定的代币，并且可以在以后重试上述步骤。 +### 实时销毁 -## 跨链转账与通信 -跨链通信是让社区利用双链结构的关键基础架构： +为了加速BNB的销毁过程并使BSC更加去中心化，部分gas费将被销毁。每个区块中，验证人收集的gas费的固定比例将被销毁。销毁比例可由BSC验证人治理设置。 -- 用户可以随意在BSC 或BC上创建任何代币化的金融产品和数字资产； -- 在 BSC上的代币可以在BC上稳定的，高吞吐，极快速和友好的环境中完成程序化交易和资产流通； -- 用户可以在统一的工具生态系统和用户界面中完成这些操作。 +## 共识和验证人法定人数 -### 跨链转账 +基于上述设计原则，BSC的共识协议旨在实现以下目标： -跨链转账是两个区块链之间通信的关键。 它的逻辑是： +1. 出块时间应比以太坊网络更短，例如3秒。 +2. 确认交易最终性需要有限的时间，例如大约10秒级或更短。 +3. 原生代币BNB没有通胀：区块奖励从交易费中收集，并将以BNB支付。 +4. 尽可能与以太坊系统兼容。 +5. 允许权益证明区块链网络治理。 -1. 转出的区块链将把来自源地址持有的金额锁定到系统控制的地址/合约中； -2. 转入区块链将解锁系统控制的地址/合约中的金额，并将其转账到目标地址。 +### 质押权威证明 -跨链转账包消息应允许BSC中继器和BC Oracle中继器验证以下信息： +尽管[工作量证明（PoW）](https://en.wikipedia.org/wiki/Proof_of_work)被认为是实现去中心化网络的实用机制，但它对环境不友好，而且还需要大量参与者来维护安全性。 -1. 从源地址中锁定了足够数量的代币资产到源区块链上的系统控制地址/合约中。 这可以在目标区块链上得到证实。 -2. 适当的代币资产额从系统控制的地址/合约中释放，并分配到目标区块链上的目标地址中。 如果失败，可以在源区块链上确认，这样锁定的代币就可以被释放回去（可能会扣除费用）。 -3. 无论转账是否成功，在此转账操作完成后，两个区块链上代币资产的流通总量都不会改变。 +以太坊和一些其他区块链网络，如MATIC Bor、TOMOChain、GoChain、xDAI，在不同场景中使用[权威证明（PoA）](https://en.wikipedia.org/wiki/Proof_of_authority)或其变体，包括测试网和主网。PoA提供了对51%攻击的一些防御，提高了效率，并对某些程度的拜占庭参与者（恶意或被黑客入侵）具有容忍度。 -![img](https://lh6.googleusercontent.com/LtYjYYoTbtUryye7n-BBBNj29cOMgzZCc1aVRfWnICEsSAMA4PBMH8_MI8jIVsV6DuS2EIvqkcfSX_h5NlC-sO7EFTJDS1Un7XgRCEgqgCLPMy-luTtW5c70-Z72wRBPlLv5xKHL) +同时，PoA协议最受批评的是不如PoW去中心化，因为验证人（即轮流产生区块的节点）拥有所有权力，容易受到腐败和安全攻击。其他区块链，如EOS和Lisk，引入了不同类型的[委托权益证明（DPoS）](https://en.wikipedia.org/wiki/Delegated_proof_of_stake)，允许代币持有者投票选举验证人集合。这增加了去中心化程度，有利于社区治理。 -跨链通信的体系结构如上图所示。 为了适应两个异构系统，通信处理在每个方向上都是不同的。 +BSC在这里提议将DPoS和PoA结合用于共识，以便： -### BC到BSC架构 +1. 区块由有限的验证人集合产生。 +2. 验证人以PoA方式轮流产生区块，类似于以太坊的Clique共识设计。 +3. 验证人集合基于基于质押的治理进行选举和退出。 +4. 为了增强网络容量，允许验证人在指定参数内产生连续区块。 -BC 是一个基于 Tendermint 的、具有即时完成确认的区块链。需要至少2/3\* N + 1 总投票权的验证人对每个区块签名。 因此可以通过**区块头**和 **Merkle 证明**验证来验证区块交易甚至状态值是可行的。这一设计已经被研究并实现为“轻客户端协议”。它被以太坊社区广泛讨论，也被用于实现Cosmos的跨链通信协议。 -从BC到BSC 通信将在通过 BSC **智能合约**实现的**“链上轻客户端”**中得到验证（其中一些是**“预编译”**合约）。在 BC 上发生一些交易和状态更改之后，如果一个交易触发跨链通信，则中继器将创建并传递跨链** “数据包”**消息，并作为数据提交到 BSC 的“轻客户端合约”上。轻客户端合约将验证跨链数据包，并在通过验证后执行交易。这类验证是通过下述设计保证： +### 验证人集合 -1. BC的区块状态将通过区块头和pre-commits同步到BSC上的轻客户端合约，以获得以下信息： +验证人集合是负责验证交易和在BSC上产生区块的节点组。验证人集合由每个验证人的质押量决定，这反映了验证人及其委托人质押的BNB数量。拥有最多质押的顶级验证人被选为活跃验证人集合，他们轮流提议和投票区块。其余的验证人在备用验证人集合中，如果他们的质押增加或某些活跃验证人退出，他们可以加入活跃验证人集合。 -* 验证人签名的 BC 区块和app哈希 -* 当前验证人集合和验证人集合更新 +任何组织或个人都可以通过在链上创建他们的验证人并获得足够的委托来成为验证人集合的一部分。同样，他们也可以通过简单地撤回所有BNB委托来选择退出。验证人也可能因为行为不当或离线而被惩罚（slashing）从验证人集合中移除。 -2. 存储于BC区块链状态中的“键-值”对将根据 Merkle 证明和上面的信息进行验证。 -在确认键-值对准确和可信之后，轻客户端合约将执行与跨链包对应的操作。 BC到BSC的跨链操作可以创建如下数据包： +在创世阶段，一些受信任的节点将作为初始验证人集合运行。在区块开始产生后，任何人都可以竞争加入成为候选人，以当选为验证人。 -* 绑定：将BEP2代币与 BEP2E绑定 -* 转账：绑定后进行跨链转账，这意味着BC上的流通将会由于锁定减少，并出现在BSC上的目标地址中，保证总流通量不变 -* 错误处理：处理 BSC到BC 通信的任何超时/失败事件 -* BSC验证人集合更新 +### 验证人选举 -为了确保没有重复、消息序列正确和超时处理，BC 引入了**“通道”**概念来管理跨链通信。 -对于中继器，请参考下面的“中继器”部分。 +验证人有不同的角色： -### BSC到BC 架构 +- **内阁：** 前K个（将是21个）获得最多出块机会的验证人。 +- **候选人：** 前(K, K+NumOfCandidates]个获得少量出块机会的验证人。 +- **非活跃：** 其余没有出块机会的验证人。 -BSC 使用了PoSA(基于权益质押的权威证明)共识协议，该协议可能会出现分叉，因此要求对更多的区块进行确认。一个区块只有一个验证人的签名，因此仅依赖一个区块不适合验证来自 BSC的数据。 -为了充分利用 BC的验证人集合信息，采用了类似于[桥接](https://github.com/poanetwork/poa-bridge)或 Oracle 区块链的思路： +![image](./assets/validator-select.png) -1. 来自BSC的跨链通信请求将作为交易提交并在BSC上执行。交易的执行将发出事件，这类事件可以被观察到，并打包成“Oracle”，发送到BC上。 这种类型的“Oracle”交易包没有区块头哈希和 Merkle 证明，而是直接包含操作的跨链信息，如发送方、接收方和要转账的金额。 -2. 为了保证 Oracle 的安全性，BC 的验证人将组建一组“Oracle 中继器”。 BC 的每个验证人都应独立运作一个 Oracle 中继器。这些Oracle 中继器将使用和BC验证人节点相同的秘钥签名、提交和投票给 BC 的跨链通信包。 任何由超过⅔\*N+1个Oracle中继器 的投票权限签名的交易包，其安全性与由 ⅔\*N+1 相同法定数量的验证人的投票权限签名的区块相同。 +验证人集合角色每24小时根据最新的质押信息确定一次。在UTC 00:00之后，共识引擎对验证人进行排序，并用排名信息更新BSC验证人集合。 -通过复用同样的验证人集合， BC 无需实现一个轻客户端，并在 BC 上持续更新区块。这样的Oracle也有 Oracle ID 和类型，以确保顺序和正确的错误处理。 +### 系统合约 +有几个内置合约（即系统合约）来促进BSC的质押和验证人选举。 -### 超时与错误处理 +- **验证人集合合约：** 该合约定期选举验证人集合。该合约还作为临时存储验证人奖励的保险库。 -在某些情况下，跨链通信会失败。 例如，由于合约中的一些编码错误，在 BSC 上无法执行中继数据包。 **在这种场景中使用超时和错误处理逻辑。** -对于可识别的用户和系统错误或任何预期的异常情况，这两个网络应该自行修复。例如，当 BC 到 BSC的转账失败时，BSC 将发出一个失败事件，Oracle 中继器将在BC 上执行退款；当 BSC 到 BC 的转账失败时，BC 将发出一个退款包给BSC中继器，以便解锁款项。 -然而，跨链通信的任何步骤都可能发生意外错误或异常。在这种情况下，BSC中继器和Oracle 中继器将发现相应的跨链通道被卡在一个特定的序列中。超时一段时间后，BSC中继器和 Oracle 中继器可以请求“SkipSequence”交易，卡住的序列将被标记为“不可执行”。 将提出相应的警告，社区必须讨论如何处理这种情况，例如通过验证人进行赔付，或者甚至在下一次网络升级期间清理错误锁定的资金。 +- **系统奖励合约：** 此合约作为收集部分交易费用的保险库。这些资金用于各种公共目的，如分发快速最终性奖励。 -### 跨链用户体验 +- **惩罚合约：** 此合约用于跟踪验证人变得不可用的次数，并在达到某个阈值时触发惩罚。此外，该合约还处理其他类型的惩罚事件，如双重签名和快速最终性中的恶意投票。 -理想情况下，用户希望使用两条平行链的方式与使用一条单链的方式相同。它需要将更多复合交易类型添加到跨链通信中以支持这一点，这将极大地增加复杂性、紧耦合和维护负担。在这里，BC和BSC只实现了基本的操作，以在初始启动时促成价值流动，并将大部分用户体验工作通过客户端实现，如钱包。例如，一个钱包可以让用户将代币直接从BSC发送订单到BC的DEX，以一种安全可靠的方式卖出代币。 +- **质押中心合约：** 此合约作为管理验证人和委托的入口点，同时实现惩罚特定验证人的逻辑。对于委托/解除委托/重新委托操作，它将调用不同验证人的实现合约来管理用户的质押。 -### 跨链合约事件 +### 奖励分配 +质押奖励来自交易费用 - 当一个区块被产生时，大部分区块费用将作为奖励收集给提议该区块的验证人。 -跨链合约事件（CCCE）是为了允许智能合约直接通过合约代码触发跨链事件而设计的。 这在下列基础上成为可能： -1. 可以提供标准的系统合约，以服务于一般智能合约可调用的操作； -2. 标准事件可以由标准合约发出； -3. Oracle 中继器可以捕获标准事件，并触发相应的跨链操作； -4. 可以在 BC 上创建专用的、代码管理的地址，并由 BSC 合约访问，这里它被命名为 “BC的合约地址”（CAoB）。 +每天，收集的奖励的一部分将直接作为佣金发送到验证人的操作员账户，而剩余部分将发送到相应的验证人信用合约。当用户解除委托并申领其质押时，累积的奖励和原始质押将返还给他/她。 -以下几个典型的标准功能将会被实现： +## 安全性和最终性 +假设有超过(N/2+1)的验证人是诚实的，基于PoA的网络通常能安全且正常工作。然而，仍有某些拜占庭验证人可能设法攻击网络的情况，例如通过"[克隆攻击](https://arxiv.org/pdf/1902.10244.pdf)"。为了确保与BC一样安全，建议BSC用户等待接收到超过2⁄3N+1个不同验证人密封的区块。这样，BSC可以被信任到与BC类似的安全级别，并且可以容忍少于1⁄3*N的拜占庭验证人。 -实现以下标准操作： +除了概率性最终性，BSC提出了一种快速最终性机制来最终确定一个区块，一旦区块被最终确定，它将永远不会被回滚。其想法与[Casper FFG](https://arxiv.org/pdf/1902.10244.pdf)非常相似。最终确定一个区块需要几个步骤： -1. BSC 到BC的转账： 这与普通的 BSC 到 BC 转账一样，都是通过标准合约触发的。 资金可以转账到 BC 上的任何地址，包括转账给原始合约中相应 CAoB 。 -2. BC内转账： 转账的完成被视为为一个特殊的跨链转账，而真正的转账是从 CAoB 到任何其他地址（甚至是另一个 CAoB）。 -3. BC 到BSC 转换： 这是以双通跨链通信的方式实现的。 第一个通道是由 BSC合约触发并传输到 BC 上，然后在第二个通道中，BC 将启动一个正常的 从BC 到 BSC的跨链转账，转账地址为 CAoB 到 BSC上的合约地址。需要特别注意的是，BSC 合约只在第二个通道转账时增加余额，第二个通道转账中的错误处理与正常的 BC 到 BSC 转账相同。 -4. IOC（立即执行或取消）交易： 将资产转移到BC 的主要目的是交易。该事件将指示将CAoB中某一资产交易为另一资产，并转移交易的剩余的目标代币，并将全部结果转账给BSC。BC将通过发送“IOC”订单来处理此类中继事件，如IOC订单发到交易对上，一旦下一次撮合完成，执行结果将被传送回BSC，其可以是一种资产，也可以是两种资产。 -5. 拍卖交易：这样的活动将指示BC发出拍卖交易，将CAoB中一定数额的资产尽可能多地转换成另一项资产，并在拍卖结束时将所有成果转回BSC。拍卖功能即将在BC上线。 +1. 一个区块由一个验证人提议并传播给其他验证人。 +2. 验证人使用他们的BLS私钥为区块签名作为投票消息。 +3. 将验证人的投票收集到一个池中。 +4. 在提议新区块时，如果其直接父区块已获得足够的投票，则聚合BLS签名。 +5. 将聚合的投票证明设置到新区块头的额外字段中。 +6. 接收到带有直接父区块证明的新区块的验证人和全节点可以证明直接父区块。 +7. 如果两个连续的区块都被证明，那么前一个区块就被最终确定。 -以下是交易的一些细节： +## 治理 +BSC引入了原生治理模块，灵感来自OpenZeppelin Governor。以下是BSC治理的主要特点： -a. 针对交易，双方都可以有一个（绝对或相对的）价格限制； -b. 最终结果将以跨链交易包的形式写入 BSC； -c. 跨链通信费用可从转回 BSC 的资产中收取； -d. BSC 合约反映了 CAoB 的余额和未完成的订单。 无论在交易期间发生什么错误，最终状态都将被传输回原始合约并清算其内部状态。 +- **提案和投票权**：质押token持有者可以提出和投票决定治理事务。 +- **持续奖励**：投票者在投票期间可以继续获得质押奖励。 +- **灵活委托**：用户可以委托他们的投票权，使其他人能够参与治理。 +- **安全执行**：提案一旦通过，在执行前会经过一个时间锁定期。 -在上述特点的基础上，将具有高流动性的跨链转账和交易功能非常方便地添加到 BSC 的所有智能合约中。 它将极大地增加在智能合约 和 dApps 上的应用场景，使币安双链产生1+1>2的聚合效应。 +BNB Chain的治理涉及两个步骤：**热点测试**和**最终决策投票**。热点测试通常通过[Snapshot](https://snapshot.org/#/)平台进行，允许任何BNB持有者评估社区对提案是否感兴趣。如果提案获得足够的支持，它将进入最终决策投票阶段。这个阶段通常涉及验证者或那些质押了BNB的人进行链上投票，结果决定提案是否被实施或拒绝。 -## 权益质押与链上治理 +## 惩罚和处罚 +惩罚是链上治理的一个组成部分，用于惩罚恶意或负面行为。任何人都可以在BSC上提交惩罚交易，这涉及提供证据和惩罚作恶者。成功的提交将获得可观的奖励。目前，有三种可惩罚的情况。 -PoSA实现了去中心化式的社区治理。 你可以从其他网络中看到类似的想法，特别是 Cosmos 和 EOS 。 其核心逻辑可概括如下。 +### 双重签名 +当一个验证者为具有相同高度和父区块的多个区块签名时，这是一个相当严重的错误，很可能是故意的违规行为。参考协议实现应该已经有逻辑来防止这种情况，所以只有恶意代码才能触发这种情况。当发生双重签名时，验证者应立即从验证者集合中移除。 -1. 代币持有者，包括验证人，可以将他们的代币 “锁定”到权益质押中。 代币持有者可以将他们的代币**委托**给任何验证人或一个验证人候选对象。 之后他们还可以重新选择不同的验证人或候选对象来对他们的代币进行委托。 -2. 所有验证人候选对象都将按其获得委托代币的数量进行排序，排名前列的将成为真正的验证人。 -3. 验证人可以与它们的委托人共享区块收益。 -4. 验证人可能会遭受**“罚息”**，即对他们的不良行为的惩罚，如双重签名和/或不稳定性。 这样的损失也会与他们的委托人共同分担。 -5. 验证人和委托人有一个 “解除绑定期”。当发现恶意拜占庭行为时，代币仍然在一定时间内保持锁定，作恶人将被及时惩罚。 +任何人都可以向BSC惩罚合约提交带有双重签名证据的惩罚交易，该证据应包含由违规验证者封存的具有相同高度和父区块的两个区块头。在收到证据后，合约将验证其有效性。 +验证者将从验证者集合中移除，预定数量的BNB将从验证者的自委托BNB中扣除。 -### BC权益质押 +### 恶意快速最终性投票 +当验证者为具有相同目标高度的两个快速最终性投票签名，或者一个投票的范围包含另一个投票的范围时，这也是一个严重的错误。参考协议实现应该已经有逻辑来防止这种情况，所以只有恶意代码才能触发这种情况。当发生**恶意投票**时，验证者应立即从验证者集合中移除。 -理想情况下，这样的权益质押和奖励发放逻辑应该包含在区块链中，并在产生新区块时自动执行。与币安链一样采用Tendermint共识库的Cosmos Hub就是这样工作的。 +任何人都可以向BSC惩罚合约提交带有恶意投票证据的惩罚交易。需要提供恶意投票的证据，包括两个冲突的投票和用于签名的投票公钥。在收到证据后，合约将验证其有效性。验证者将从当前验证者集合中移除，提交者将从系统合约获得奖励。 -自设计之日起，BC就一直在准备启用PoS。另一方面，BSC想要尽可能地与以太坊保持兼容，在其上直接实现PoSA是一个巨大的挑战和压力。特别是考虑到以太坊本身可能在短时间（或更长时间）内迁移到PoS共识协议时，尤其如此。为了保持以太坊的兼容性和复用BC的基础架构，我们在BC上完成了BSC的权益质押逻辑： +### 不可用性 +BSC的活跃性依赖于权益证明授权验证者集合中的每个人在轮到他们时及时产生区块。验证者可能因为任何原因错过他们的回合，特别是硬件、软件、配置或网络问题。这种操作的不稳定性将损害性能并给系统引入更多的不确定性。 -1. 质押代币是 BNB，这是因为它是两个区块链上的原生代币。 -2. 在BC上记录BSC的权益质押和委托行为。 -3. BSC 验证人集由它的权益质押和委托逻辑来决定，在BC上构建一个BSC的权益质押模块，并通过跨链通信在每天UTC 00:00:00 由BC传送到 BSC 。 -4. BC上的奖励分配发生在每天UTC 00:00时刻。 - -### 奖励 - -验证人集更新和奖励分配都发生在每天 的UTC 00:00 。这是为了节省频繁更新和区块奖励分配的成本。频繁分配奖励的代价可能是巨大的，因为区块奖励是在BSC上收取的，并在BC上分发给BSC验证人和委托人。（请注意，BC出块奖励仅分发给BC验证人。） - -为了确保分配是公平的，这里引入了一种延后分配的算法： - -1. 区块奖励不会立即发送给验证人，而是计算并积累在智能合约中； -2. 当BSC收到验证人集更新消息时，它将触发跨链转账，将奖励转账给验证人的托管地址。 托管地址是由系统控制，因此在向委派者承诺的分配完成之前，奖金是不能用的。 -3. 为了使同步更简单，并分配时间以防出现罚没，第T天的奖励将在第T + 2 天分配。 在委托人收到奖励后，剩下的收益将被转移到验证人自己的奖励地址。 - -### 罚息 - -罚息是链上管理的一部分，以确保恶意或负面行为受到惩罚。 BSC罚息证据可以由任何人提交。 交易提交要求提交罚息证据和缴纳手续费，但一旦成功提交，也带来了更多奖励。 - -到目前为止，有两种可以被惩罚的情况。 - -**双重签名** - -当验证人故意签署多个相同高度并具有相同父块的区块时，这是很严重的作恶行为。 协议的实现应该已经考虑到如何防止这种情况发生，因此只有恶意代码才能触发这种情况。当出现双重签名时，验证人应该立即从验证人集合中移除。 - -任何人都可以在 BC 上提交带有 BSC 双重签名的罚息请求，应该包含两个具有相同高度的区块头和母区块，以及违规验证人的签名。 在收到证据后，如果 BC 确认该证据是有效的： - -1. 该验证人将立刻发送 BSC “验证人集合更新”跨链消息，恶意验证人将从验证集中剔除； -2. 验证人的权益质押将按照预先设定的金额进行惩罚； -3. 一部分被惩罚的BNB 将奖励给证据提交者。奖励金额应远远大于提交罚息请求事件的成本 -4. 剩下的 BNB 将分配给其他验证人的托管地址，并以与区块奖励相同的方式分配给所有委托人。 - -**不稳定性** - -BSC 的可用性依赖于PoSA共识中验证人集合中的每个验证人，当轮到其出块时，他们能够及时生成区块。 验证人可能由于一些原因而错过出块时机，特别是由于硬件、软件、配置或网络方面的问题。 这种不稳定运行将损害网络的性能，并给系统带来更多的不确定性。 - -BSC有一个内部的合约，负责记录每个验证人错过的区块。 一旦该指标超过预定义的阈值，验证人的区块奖励将不会被转移到 BC 进行分发，而是被其他更好的验证人共享。通过这种方式，运行不良的验证人会逐渐退出，因为它们的委托人将获得较少奖励或没有奖励。如果该数据仍然高于另一个较高的阈值级别，验证人将受到惩罚，并将传输回BC，在BC中，验证人的的抵押资产将被罚没一部分。 - -**参数管理** - -有许多系统参数来控制 BSC 的行为，如罚息阈值和数量，跨链转账费用等。所有这些参数将由 BSC 验证人通过提案投票过程确定。此过程将在 BC 上进行，系统合约将通过跨链通信来获取最新参数。 - -## 中继器 - -中继器负责提交两个区块链之间的跨链通信包。 由于并联链结构的异构性，产生了两种不同类型的中继器。 - -### BSC中继器 - -BC 到 BSC 通信的中继器称为 “BSC 中继器”，或简称为 “中继器”。 中继器是一个独立的进程，任何人都可以在任何地方运行，但是中继器必须在BSC 注册并锁定一定数量的 BNB 。 BSC将只接受来自已注册的中继器的中继请求。 - -它们所传递的数据包将由 BSC 上的链上轻客户端进行验证。中继成功需要通过足够的验证，并在BSC上支付足够的手续费，因此，应该有激励性奖励来鼓励社区经营中继器。 - -#### 激励 - -有两种主要的沟通方式： - -1. 客户端操作，如跨链绑定、转账和错误处理等。 这应该由事件请求者支付。 -2. 系统同步，例如传递“退回资金”数据包（由于大多数Oracle中继失败造成的），或者用于验证的区块头，以及验证人集合更新。以上奖励由 BSC 系统合约支付。 - -如果某些中继器有更快的网络和更好的硬件，它们可以垄断所有的中继包，而不会给其他中继器留下任何收益。 因此，将有更少的参与者加入中继，这将鼓励集中化，但损害网络的效率和安全。 理想情况下，由于 BSC 验证人的分散化和动态重新选择，一个中继器不可能总是第一个传递每个消息。 但是为了避免进一步的垄断，奖励经济机制也是专门为尽量减少这种机会而设计的： - -1. 对中继器的奖励将只分批次发放，而一次发放将覆盖多个成功的中继器包。 -2. 一个中继器可以从批处理分发中获得的报酬与成功中继包的数量并不是成比例的。 相反，除了前几个数据包，在一个批次期间中继器传递传递数据包越多，它将获得的报酬越少。 - -### Oracle中继器 - -BSC 到 BC 通信的中继器使用 “Oracle”模型，也就是所谓的 “Oracle 中继器”。 每个BC验证人都必须（只有验证集合中的验证人可以）运行 Oracle 中继器。 每个 Oracle 中继器都会观察 BSC状态的变化。 一旦它捕获到跨链通信包，它将提交投票请求。在获得大于2/3投票支持更改之后，将执行跨链操作。 - -Oracle 中继器应该等待足够的区块来确认 BSC 的最终结果，然后才向 BC 提交和投票跨链通信包。 - -跨链费用将与正常的 BC 区块奖励一起分配给 BC 验证人。 - -此种 Oracle中继器依赖于所有验证人的支持。 由于跨链通信包的所有投票都记录在区块链上，因此评估 Oracle 中继器的性能并不难。将来可能会通过引入的另一种惩罚机制来限制表现最差的验证人的收益。 +BSC有一个内部智能合约记录每个验证者的错过区块数量。如果这个指标超过设定的阈值，验证者的区块奖励将不会给予他们，而是与表现更好的其他验证者共享。这个过程旨在逐步从集合中移除运营不佳的验证者，减少他们的委托者的奖励。 +如果指标保持在更高的阈值以上，验证者将从轮换中移除，并从他们的自委托BNB中扣除一定数量的BNB。这个行为导致验证者和委托者都无法获得他们的质押奖励。 ## 展望 +我们很难对BNB Chain下定论，因为它从未停止发展。以下是我们目前最关注的主题，这些特性的发展会为社区提供更好的可用性和可扩展性： -对于币安链的未来，很难做出一个定论，因为它从未停止进化。双链策略一方面为用户打开了灵活可扩展的编程之门，另一方面为用户保留了极速交易合转账的便利，但这只是币安链发展的一个阶段。以下是一些值得关注的主题，以促进社区更好地获得更多的可用性和可扩展性： - -1.为不同的业务用例添加不同的数字资产模型 -2.实现将更多的数据源，特别是 DEX 市场数据，从币安 DEX传输到BSC -3.提供兼容以太坊及其未来升级，以及其他区块链的接口 -4.改进钱包和区块链客户端的可用性 - - - - +- **并行EVM**。并行EVM是EVM的一个扩展，允许它并行执行多个指令，从而提高网络的性能。 +- **状态过期**。通过移除过期的存储状态，解决BNB智能链上不断增加的世界状态存储问题。 +- **持续进一步去中心化**。 +- **大规模采用基础设施**。BNB Chain社区致力于确保公共基础设施是一流的，并为大规模应用提供基础构建块。 \ No newline at end of file diff --git a/README.md b/README.md index 15c1271..1f681f4 100644 --- a/README.md +++ b/README.md @@ -5,3 +5,4 @@ * Version 0.1, 2020/04/17, initial publish. * Version 0.1, 2020/05/25, add Chinese version translated by community members. * Version 0.1, 2020/11/10, add Filipino version translated by @ricoz +* Version 0.2, 2024/8/7, revise the whitepaper after BC fusion \ No newline at end of file diff --git a/WHITEPAPER.md b/WHITEPAPER.md index 1c1ade4..28f06c7 100644 --- a/WHITEPAPER.md +++ b/WHITEPAPER.md @@ -1,355 +1,202 @@ # BNB Smart Chain -**A Parallel Blockchain to Beacon Chain to Enable Smart Contracts** -_NOTE: This document is under development. Please check regularly for updates!_ +## Table of Contents ## Table of Contents + +- [BNB Smart Chain](#bnb-smart-chain) - [Motivation](#motivation) +- [Evolution of BNB Chain](#evolution-of-bnb-chain) - [Design Principles](#design-principles) -- [Consensus and Validator Quorum](#consensus-and-validator-quorum) - * [Proof of Staked Authority](#proof-of-staked-authority) - * [Validator Quorum](#validator-quorum) - * [Security and Finality](#security-and-finality) - * [Reward](#reward) - [Token Economy](#token-economy) - * [Native Token](#native-token) - * [Other Tokens](#other-tokens) -- [Cross-Chain Transfer and Communication](#cross-chain-transfer-and-communication) - * [Cross-Chain Transfer](#cross-chain-transfer) - * [BC to BSC Architecture](#bc-to-bsc-architecture) - * [BSC to BC Architecture](#bsc-to-bc-architecture) - * [Timeout and Error Handling](#timeout-and-error-handling) - * [Cross-Chain User Experience](#cross-chain-user-experience) - * [Cross-Chain Contract Event](#cross-chain-contract-event) -- [Staking and Governance](#staking-and-governance) - * [Staking on BC](#staking-on-bc) - * [Rewarding](#rewarding) - * [Slashing](#slashing) -- [Relayers](#relayers) - * [BSC Relayers](#bsc-relayers) - * [Oracle Relayers](#oracle-relayers) + - [Native Token](#native-token) + - [Seed Fund](#seed-fund) + - [Real-Time Burning](#real-time-burning) +- [Consensus and Validator Quorum](#consensus-and-validator-quorum) + - [Proof of Staked Authority](#proof-of-staked-authority) + - [Validator Set](#validator-set) + - [Validator Election](#validator-election) +- [System Contracts](#system-contracts) +- [Reward Distribution](#reward-distribution) +- [Security and Finality](#security-and-finality) +- [Governance](#governance) +- [Slashing and Penalties](#slashing-and-penalties) + - [Double Sign](#double-sign) + - [Malicious Fast Finality Vote](#malicious-fast-finality-vote) + - [Unavailability](#unavailability) - [Outlook](#outlook) -# Motivation - -After its mainnet community [launch](https://www.binance.com/en/blog/327334696200323072/Binance-DEX-Launches-on-Binance-Chain-Invites-Further-Community-Development) in April 2019, [Beacon Chain](https://www.bnbchain.org/en) has exhibited its high speed and large throughput design. Beacon Chain’s primary focus, its native [decentralized application](https://en.wikipedia.org/wiki/Decentralized_application) (“dApp”) [BNB DEX](https://www.bnbchain.org/trade), has demonstrated its low-latency matching with large capacity headroom by handling millions of trading volume in a short time. -Flexibility and usability are often in an inverse relationship with performance. The concentration on providing a convenient digital asset issuing and trading venue also brings limitations. Beacon Chain's most requested feature is the programmable extendibility, or simply the [Smart Contract](https://en.wikipedia.org/wiki/Smart_contract) and Virtual Machine functions. Digital asset issuers and owners struggle to add new decentralized features for their assets or introduce any sort of community governance and activities. +## Motivation -Despite this high demand for adding the Smart Contract feature onto Beacon Chain, it is a hard decision to make. The execution of a Smart Contract may slow down the exchange function and add non-deterministic factors to trading. If that compromise could be tolerated, it might be a straightforward idea to introduce a new Virtual Machine specification based on [Tendermint](https://tendermint.com/core/), based on the current underlying consensus protocol and major RPC implementation of Beacon Chain. But all these will increase the learning requirements for all existing dApp communities, and will not be very welcomed. +After its mainnet community launch in April 2019, Beacon Chain has exhibited its high speed and large throughput design. The primary focus of Beacon Chain is to support a native, low-latency, and high-performance decentralized exchange. Among the most requested features is programmable extendibility, specifically the implementation of smart contracts and virtual machine functions. To address this demand, we propose the BNB Smart Chain, running parallel to Beacon Chain, to facilitate a user-friendly smart contract environment. -We propose a parallel blockchain of the current Beacon Chain to retain the high performance of the native DEX blockchain and to support a friendly Smart Contract function at the same time. +BNB Smart Chain (BSC) is an EVM-compatible blockchain designed to bring programmability and interoperability to the BNB Chain ecosystem. As part of the broader BNB Chain, BSC aims to deliver a high-throughput, low-latency, and low-cost environment for decentralized applications (dApps) and digital assets. This whitepaper outlines the architecture, mechanisms, and evolutionary journey of BSC. While several years old, we maintain this paper because it continues to serve as a useful reference and an accurate representation of BNB Smart Chain. -# Design Principles +## Evolution of BNB Chain -After the creation of the parallel blockchain into the BNB Chain ecosystem, two blockchains will run side by side to provide different services. The new parallel chain will be called “**BNB Smart Chain**” (short as “**BSC**” for the below sections), while the existing mainnet will be named “**Beacon Chain**” (short as “**BC**” for the below sections). +- **Initial Launch and Beacon Chain.** Beacon Chain, launched in April 2019, was designed to support the BNB DEX and exhibited high speed and large throughput. However, its lack of programmability and smart contract functionality posed limitations for developers and users. -Here are the design principles of **BSC**: +- **Introduction of BNB Smart Chain.** To address these limitations, BNB Smart Chain was introduced in 2020, leveraging a parallel blockchain architecture to support smart contracts while retaining high performance for the DEX. -1. **Standalone Blockchain**: technically, BSC is a standalone blockchain, instead of a layer-2 solution. Most BSC fundamental technical and business functions should be self-contained so that it can run well even if the BC stopped for a short period. -2. **Ethereum Compatibility**: The first practical and widely-used Smart Contract platform is Ethereum. To take advantage of the relatively mature applications and community, BSC chooses to be compatible with the existing Ethereum mainnet. This means most of the **dApps**, ecosystem components, and toolings will work with BSC and require zero or minimum changes; BSC node will require similar (or a bit higher) hardware specification and skills to run and operate. The implementation should leave room for BSC to catch up with further Ethereum upgrades. -3. **Staking Involved Consensus and Governance**: Staking-based consensus is more environmentally friendly and leaves more flexible option to the community governance. Expectedly, this consensus should enable better network performance over [proof-of-work](https://en.wikipedia.org/wiki/Proof_of_work) blockchain system, i.e., faster blocking time and higher transaction capacity. -4. **Native Cross-Chain Communication**: both BC and BSC will be implemented with native support for cross-chain communication among the two blockchains. The communication protocol should be bi-directional, decentralized, and trustless. It will concentrate on moving digital assets between BC and BSC, i.e., [BEP2](https://github.com/bnb-chain/BEPs/blob/master/BEP2.md) tokens, and eventually, other BEP tokens introduced later. The protocol should care for the minimum of other items stored in the state of the blockchains, with only a few exceptions. - -# Consensus and Validator Quorum - -Based on the above design principles, the consensus protocol of BSC is to fulfill the following goals: - -1. Blocking time should be shorter than Ethereum network, e.g. 5 seconds or even shorter. -2. It requires limited time to confirm the finality of transactions, e.g. around 1-min level or shorter. -3. There is no inflation of native token: BNB, the block reward is collected from transaction fees, and it will be paid in BNB. -4. It is compatible with Ethereum system as much as possible. -5. It allows modern [proof-of-stake](https://en.wikipedia.org/wiki/Proof_of_stake) blockchain network governance. +- **BNB Chain Fusion.** In November 2023, the BNB Chain Fusion proposal ([BEP-333](https://github.com/binance-chain/BEPs/blob/master/BEP333.md)) marked a significant shift. This proposal outlined the sunset of the Beacon Chain, merging its functionalities with BSC to create a unified, high-performance blockchain network. This fusion aimed to streamline operations, enhance security, and simplify the user experience on BSC. -## Proof of Staked Authority +- **opBNB.** Launched in 2023, opBNB is an Ethereum Virtual Machine (EVM)-compatible Layer 2 chain based on the Optimism OP Stack. It aims to revolutionize the blockchain industry by providing lower gas fees and democratizing access to blockchain technology. -Although Proof-of-Work (PoW) has been recognized as a practical mechanism to implement a decentralized network, it is not friendly to the environment and also requires a large size of participants to maintain the security. +- **BNB Greenfield.** Greenfield is a novel decentralized data storage network with a native bridge to BNB Smart Chain (BSC), which manages user rights, bucket creation, and file deletion to transform the way users interact with their data. -Ethereum and some other blockchain networks, such as [MATIC Bor](https://github.com/maticnetwork/bor), [TOMOChain](https://tomochain.com/), [GoChain](https://gochain.io/), [xDAI](https://xdai.io/), do use [Proof-of-Authority(PoA)](https://en.wikipedia.org/wiki/Proof_of_authority) or its variants in different scenarios, including both testnet and mainnet. PoA provides some defense to 51% attack, with improved efficiency and tolerance to certain levels of Byzantine players (malicious or hacked). It serves as an easy choice to pick as the fundamentals. +BNB Chain is a continuously evolving ecosystem with BSC at its core. As a critical financial system, BSC hosts the most crypto asset values. It also serves as the settlement and data availability layer for opBNB and other Layer 2 solutions, ensuring the security of layer2s. Additionally, BSC functions as the smart contract programming platform for Greenfield, facilitating data exchange and circulation within Greenfield. -Meanwhile, the PoA protocol is most criticized for being not as decentralized as PoW, as the validators, i.e. the nodes that take turns to produce blocks, have all the authorities and are prone to corruption and security attacks. Other blockchains, such as EOS and Lisk both, introduce different types of [Delegated Proof of Stake (DPoS)](https://en.bitcoinwiki.org/wiki/DPoS) to allow the token holders to vote and elect the validator set. It increases the decentralization and favors community governance. - -BSC here proposes to combine DPoS and PoA for consensus, so that: -1. Blocks are produced by a limited set of validators -2. Validators take turns to produce blocks in a PoA manner, similar to [Ethereum’s Clique](https://eips.ethereum.org/EIPS/eip-225) consensus design -3. Validator set are elected in and out based on a staking based governance - -## Validator Quorum - -In the genesis stage, a few trusted nodes will run as the initial Validator Set. After the blocking starts, anyone can compete to join as candidates to elect as a validator. The staking status decides the top 21 most staked nodes to be the next validator set, and such an election will repeat every 24 hours. - -**BNB** is the token used to stake for BSC. - -In order to remain as compatible as Ethereum and upgradeable to future consensus protocols to be developed, BSC chooses to rely on the **BC** for staking management (Please refer to the below “[Staking and Governance](#staking-and-governance)” section). There is a **dedicated staking module for BSC on BC**. It will accept BSC staking from BNB holders and calculate the highest staked node set. Upon every UTC midnight, BC will issue a verifiable `ValidatorSetUpdate` cross-chain message to notify BSC to update its validator set. - -While producing further blocks, the existing BSC validators check whether there is a `ValidatorSetUpdate` message relayed onto BSC periodically. If there is, they will update the validator set after an **epoch period**, i.e. a predefined number of blocking time. For example, if BSC produces a block every 5 seconds, and the epoch period is 240 blocks, then the current validator set will check and update the validator set for the next epoch in 1200 seconds (20 minutes). - -## Security and Finality +BSC has evolved significantly from its initial dual-chain architecture, where staking, validation, and governance were delegated to the Beacon Chain. After the BC fusion, BSC transitioned into a fully autonomous chain, undergoing substantial architectural changes. -Given there are more than ½\*N+1 validators are honest, PoA based networks usually work securely and properly. However, there are still cases where certain amount Byzantine validators may still manage to attack the network, e.g. through the “[Clone Attack](https://arxiv.org/pdf/1902.10244.pdf)”. To secure as much as BC, BSC users are encouraged to wait until receiving blocks sealed by more than ⅔\*N+1 different validators. In that way, the BSC can be trusted at a similar security level to BC and can tolerate less than ⅓\*N Byzantine validators. +## Design Principles -With 21 validators, if the block time is 5 seconds, the ⅔\*N+1 different validator seals will need a time period of (⅔\*21+1)*5 = 75 seconds. Any critical applications for BSC may have to wait for ⅔\*N+1 to ensure a relatively secure finality. However, besides such arrangement, BSC does introduce **Slashing** logic to penalize Byzantine validators for **double signing** or **unavailability**, which will be covered in the “Staking and Governance” section later. This Slashing logic will expose the malicious validators in a very short time and make the “Clone Attack” very hard or extremely non-beneficial to execute. With this enhancement, ½\*N+1 or even fewer blocks are enough as confirmation for most transactions. +Here are the design principles of BSC: -## Reward +1. **Standalone Blockchain:** Technically, BSC is a standalone blockchain, instead of a layer-2 solution. Most BSC fundamental technical and business functions should be self-contained so that it can run well even if the BC stopped for a short period. -All the BSC validators in the current validator set will be rewarded with transaction **fees in BNB**. As BNB is not an inflationary token, there will be no mining rewards as what Bitcoin and Ethereum network generate, and the gas fee is the major reward for validators. As BNB is also utility tokens with other use cases, delegators and validators will still enjoy other benefits of holding BNB. +2. **Ethereum Compatibility:** The first practical and widely-used Smart Contract platform is Ethereum. To take advantage of the relatively mature applications and community, BSC chooses to be compatible with the existing Ethereum mainnet. This means most of the dApps, ecosystem components, and toolings will work with BSC and require zero or minimum changes; a BSC node will require similar (or a bit higher) hardware specification and skills to run and operate. The implementation should leave room for BSC to catch up with further Ethereum upgrades. -The reward for validators is the fees collected from transactions in each block. Validators can decide how much to give back to the delegators who stake their BNB to them, in order to attract more staking. Every validator will take turns to produce the blocks in the same probability (if they stick to 100% liveness), thus, in the long run, all the stable validators may get a similar size of the reward. Meanwhile, the stakes on each validator may be different, so this brings a counter-intuitive situation that more users trust and delegate to one validator, they potentially get less reward. So rational delegators will tend to delegate to the one with fewer stakes as long as the validator is still trustful (insecure validator may bring slashable risk). In the end, the stakes on all the validators will have less variation. This will actually prevent the stake concentration and “winner wins forever” problem seen on some other networks. +3. **Staking Involved Consensus and Governance:** Staking-based consensus is more environmentally friendly and leaves more flexible options to community governance. Expectedly, this consensus should enable better network performance over [proof-of-work](https://en.wikipedia.org/wiki/Proof_of_work) blockchain systems, i.e., faster blocking time and higher transaction capacity. -Some parts of the gas fee will also be rewarded to relayers for Cross-Chain communication. Please refer to the “[Relayers](#relayers)” section below. +4. **Rapid Blocking Time and Fast Finality:** BSC will implement a fast finality mechanism, allowing for blocks to be finalized within two block confirmations under normal circumstances. This feature, combined with BSC's swift block time of 3 seconds, offers near-instant transaction finality and good user experience. -# Token Economy +## Token Economy -BC and BSC share the same token universe for BNB and BEP2 tokens. This defines: +BSC, opBNB, and Greenfield share the same token universe for BNB. This defines: -1. The same token can circulate on both networks, and flow between them bi-directionally via a cross-chain communication mechanism. -2. The total circulation of the same token should be managed across the two networks, i.e. the total effective supply of a token should be the sum of the token’s total effective supply on both BSC and BC. -3. The tokens can be initially created on BSC in a similar format as ERC20 token standard, or on BC as a BEP2, then created on the other. There are native ways on both networks to link the two and secure the total supply of the token. +1. BNB can circulate on all networks and flow via a cross-chain communication mechanism. +2. The total circulation of the BNB should be managed across the three networks, i.e., the total effective supply of BNB should be the sum of the token's total effective supply across all networks. -## Native Token +### Native Token -BNB will run on BSC in the same way as ETH runs on Ethereum so that it remains as “native token” for both BSC and BC. This means, in addition to BNB is used to pay most of the fees on Beacon Chain and BNB DEX, BNB will be also used to: +BNB will run on BSC in the same way as ETH runs on Ethereum so that it remains as the "native token" for BSC. This means BNB will be used to: -1. pay “fees“ to deploy smart contracts on BSC -2. stake on selected BSC validators, and get corresponding rewards -3. perform cross-chain operations, such as transfer token assets across BC and BSC +1. Pay "fees" to deploy smart contracts on BSC. +2. Stake on selected BSC validators and get corresponding rewards. +3. Perform cross-chain operations, such as transferring token assets across BSC, opBNB, and Greenfield. ### Seed Fund -Certain amounts of BNB will be burnt on BC and minted on BSC during its genesis stage. This amount is called “Seed Fund” to circulate on BSC after the first block, which will be dispatched to the initial BC-to-BSC Relayer(described in later sections) and initial validator set introduced at genesis. These BNBs are used to pay transaction fees in the early stage to transfer more BNB from BC onto BSC via the cross-chain mechanism. - -The BNB cross-chain transfer is discussed in a later section, but for BC to BSC transfer, it is generally to lock BNB on BC from the source address of the transfer to a system-controlled address and unlock the corresponding amount from special contract to the target address of the transfer on BSC, or reversely, when transferring from BSC to BC, it is to lock BNB from the source address on BSC into a special contract and release locked amount on BC from the system address to the target address. The logic is related to native code on BC and a series of smart contracts on BSC. - -## Other Tokens - -BC supports BEP2 tokens and upcoming [BEP8 tokens](https://github.com/bnb-chain/BEPs/pull/69), which are native assets transferrable and tradable (if listed) via fast transactions and sub-second finality. Meanwhile, as BSC is Ethereum compatible, it is natural to support ERC20 tokens on BSC, which here is called “**BEP2E**” (with the real name to be introduced by the future BEPs,it potentially covers BEP8 as well). BEP2E may be “Enhanced” by adding a few more methods to expose more information, such as token denomination, decimal precision definition and the owner address who can decide the Token Binding across the chains. BSC and BC work together to ensure that one token can circulate in both formats with confirmed total supply and be used in different use cases. - -### Token Binding - -BEP2 tokens will be extended to host a new attribute to associate the token with a BSC BEP2E token contract, called “**Binder**”, and this process of association is called “**Token Binding**”. - -Token Binding can happen at any time after BEP2 and BEP2E are ready. The token owners of either BEP2 or BEP2E don’t need to bother about the Binding, until before they really want to use the tokens on different scenarios. Issuers can either create BEP2 first or BEP2E first, and they can be bound at a later time. Of course, it is encouraged for all the issuers of BEP2 and BEP2E to set the Binding up early after the issuance. - -A typical procedure to bind the BEP2 and BEP2E will be like the below: - -1. Ensure both the BEP2 token and the BEP2E token both exist on each blockchain, with the same total supply. BEP2E should have 3 more methods than typical ERC20 token standard: - * symbol(): get token symbol - * decimals(): get the number of the token decimal digits - * owner(): get **BEP2E contract owner’s address.** This value should be initialized in the BEP2E contract constructor so that the further binding action can verify whether the action is from the BEP2E owner. - -2. Decide the initial circulation on both blockchains. Suppose the total supply is *S*, and the expected initial circulating supply on BC is *K*, then the owner should lock S-K tokens to a system controlled address on BC. - -3. Equivalently, *K* tokens is locked in the special contract on BSC, which handles major binding functions and is named as **TokenHub**. The issuer of the BEP2E token should lock the *K* amount of that token into TokenHub, resulting in *S-K* tokens to circulate on BSC. Thus the total circulation across 2 blockchains remains as *S*. - -4. The issuer of BEP2 token sends the bind transaction on BC. Once the transaction is executed successfully after proper verification: - * It transfers *S-K* tokens to a system-controlled address on BC. - * A cross-chain bind request package will be created, waiting for Relayers to relay. - -5. BSC Relayers will relay the cross-chain bind request package into **TokenHub** on BSC, and the corresponding request and information will be stored into the contract. - -6. The contract owner and only the owner can run a special method of TokenHub contract, `ApproveBind`, to verify the binding request to mark it as a success. It will confirm: - * the token has not been bound; - * the binding is for the proper symbol, with proper total supply and decimal information; - * the proper lock are done on both networks; - -10. Once the `ApproveBind` method has succeeded, TokenHub will mark the two tokens are bounded and share the same circulation on BSC, and the status will be propagated back to BC. After this final confirmation, the BEP2E contract address and decimals will be written onto the BEP2 token as a new attribute on BC, and the tokens can be transferred across the two blockchains bidirectionally. If the ApproveBind fails, the failure event will also be propagated back to BC to release the locked tokens, and the above steps can be re-tried later. - -# Cross-Chain Transfer and Communication -Cross-chain communication is the key foundation to allow the community to take advantage of the dual chain structure: - -* users are free to create any tokenization, financial products, and digital assets on BSC or BC as they wish -* the items on BSC can be manually and programmingly traded and circulated in a stable, high throughput, lighting fast and friendly environment of BC -* users can operate these in one UI and tooling ecosystem. - -## Cross-Chain Transfer - -The cross-chain transfer is the key communication between the two blockchains. Essentially the logic is: +Certain amounts of BNB will be burnt on Beacon Chain and minted on BSC during its genesis stage. This amount is called "Seed Fund" to circulate on BSC after the first block, which will be dispatched to the initial validator set introduced at genesis. -1. the `transfer-out` blockchain will lock the amount from source owner addresses into a system controlled address/contracts; -2. the `transfer-in` blockchain will unlock the amount from the system controlled address/contracts and send it to target addresses. +### Real-Time Burning -The cross-chain transfer package message should allow the BSC Relayers and BC **Oracle Relayers** to verify: +To speed up the burning process of BNB and make BSC more decentralized, part of the gas fee will be burned. A fixed ratio of the gas fee collected by the validators will be burned in each block. The burning ratio can be governed by the BSC validators. -1. Enough amount of token assets are removed from the source address and locked into a system controlled addresses/contracts on the source blockchain. And this can be confirmed on the target blockchain. -2. Proper amounts of token assets are released from a system controlled addresses/contracts and allocated into target addresses on the target blockchain. If this fails, it can be confirmed on source blockchain, so that the locked token can be released back (may deduct fees). -3. The sum of the total circulation of the token assets across the 2 blockchains are not changed after this transfer action completes, no matter if the transfer succeeds or not. +## Consensus and Validator Quorum -![cross-chain](./assets/cross-chain.png) - -The architecture of cross-chain communication is as in the above diagram. To accommodate the 2 heteroid systems, communication handling is different in each direction. - -## BC to BSC Architecture - -BC is a Tendermint-based, instant finality blockchain. Validators with at least ⅔\*N+1 of the total voting power will co-sign each block on the chain. So that it is practical to verify the block transactions and even the state value via **Block Header** and **Merkle Proof** verification. This has been researched and implemented as “**Light-Client Protocol**”, which are intensively discussed in [the Ethereum](https://github.com/ethereum/wiki/wiki/Light-client-protocol) community, studied and implemented for [Cosmos inter-chain communication](https://github.com/cosmos/ics/blob/a4173c91560567bdb7cc9abee8e61256fc3725e9/spec/ics-007-tendermint-client/README.md). - -BC-to-BSC communication will be verified in an “**on-chain light client**” implemented via BSC **Smart Contracts** (some of them may be **“pre-compiled”**). After some transactions and state change happen on BC, if a transaction is defined to trigger cross-chain communication,the Cross-chain “**package**” message will be created and **BSC Relayers** will pass and submit them onto BSC as data into the "build-in system contracts". The build-in system contracts will verify the package and execute the transactions if it passes the verification. The verification will be guaranteed with the below design: - -1. BC blocking status will be synced to the light client contracts on BSC from time to time, via block header and pre-commits, for the below information: - * block and app hash of BC that are signed by validators - * current validatorset, and validator set update - -2. the key-value from the blockchain state will be verified based on the Merkle Proof and information from above #1. - -After confirming the key-value is accurate and trustful, the build-in system contracts will execute the actions corresponding to the cross-chain packages. Some examples of such packages that can be created for BC-to-BSC are: - -1. Bind: bind the BEP2 tokens and BEP2E -2. Transfer: transfer tokens after binding, this means the circulation will decrease (be locked) from BC and appear in the target address balance on BSC -3. Error Handling: to handle any timeout/failure event for BSC-to-BC communication -4. Validatorset update of BSC - -To ensure no duplication, proper message sequence and timely timeout, there is a “Channel” concept introduced on BC to manage any types of the communication. - -For relayers, please also refer to the below “Relayers” section. - -## BSC to BC Architecture - -BSC uses Proof of Staked Authority consensus protocol, which has a chance to fork and requires confirmation of more blocks. One block only has the signature of one validator, so that it is not easy to rely on one block to verify data from BSC. +Based on the above design principles, the consensus protocol of BSC is to fulfill the following goals: -To take full advantage of validator quorum of BC, an idea similar to many [Bridge](https://github.com/poanetwork/poa-bridge) or Oracle blockchains is adopted: +1. Blocking time should be shorter than the Ethereum network, e.g., 3 seconds. +2. It requires limited time to confirm the finality of transactions, e.g., around 10-seconds level or shorter. +3. There is no inflation of native token: BNB, the block reward is collected from transaction fees, and it will be paid in BNB. +4. It is compatible with the Ethereum system as much as possible. +5. It allows modern proof-of-stake blockchain network governance. -1. The cross-chain communication requests from BSC will be submitted and executed onto BSC as transactions. The execution of the transaction will emit `Events`, and such events can be observed and packaged in certain “**Oracle**” onto BC. Instead of Block Headers, Hash and Merkle Proof, this type of “Oracle” package directly contains the cross-chain information for actions, such as sender, receiver and amount for transfer. -2. To ensure the security of the Oracle, the validators of BC will form another quorum of “**Oracle Relayers**”. Each validator of the BC should run a **dedicated process** as the Oracle Relayer. These Oracle Relayers will submit and vote for the cross-chain communication package, like Oracle, onto BC, using the same validator keys. Any package signed by more than ⅔\*N+1 Oracle Relayers’ voting power is as secure as any block signed by ⅔\*N+1 of the same quorum of validators’ voting power. +### Proof of Staked Authority -By using the same validator quorum, it saves the light client code on BC and continuous block updates onto BC. Such Oracles also have Oracle IDs and types, to ensure sequencing and proper error handling. +Although [Proof-of-Work (PoW)](https://en.wikipedia.org/wiki/Proof_of_work) has been recognized as a practical mechanism to implement a decentralized network, it is not friendly to the environment and also requires a large size of participants to maintain the security. -## Timeout and Error Handling +Ethereum and some other blockchain networks, such as MATIC Bor, TOMOChain, GoChain, xDAI, use [Proof-of-Authority (PoA)](https://en.wikipedia.org/wiki/Proof_of_authority) or its variants in different scenarios, including both testnet and mainnet. PoA provides some defense to 51% attack, with improved efficiency and tolerance to certain levels of Byzantine players (malicious or hacked). It serves as an easy choice to pick as the fundamentals. -There are scenarios that the cross-chain communication fails. For example, the relayed package cannot be executed on BSC due to some coding bug in the contracts. **Timeout and error handling logics are** used in such scenarios. +Meanwhile, the PoA protocol is most criticized for being not as decentralized as PoW, as the validators, i.e., the nodes that take turns to produce blocks, have all the authorities and are prone to corruption and security attacks. Other blockchains, such as EOS and Lisk, introduce different types of [Delegated Proof of Stake (DPoS)](https://en.wikipedia.org/wiki/Delegated_proof_of_stake) to allow the token holders to vote and elect the validator set. It increases decentralization and favors community governance. -For the recognizable user and system errors or any expected exceptions, the two networks should heal themselves. For example, when BC to BSC transfer fails, BSC will issue a failure event and Oracle Relayers will execute a refund on BC; when BSC to BC transfer fails, BC will issue a refund package for Relayer to relay in order to unlock the fund. +BSC here proposes to combine DPoS and PoA for consensus, so that: -However, unexpected error or exception may still happen on any step of the cross-chain communication. In such a case, the Relayers and Oracle Relayers will discover that the corresponding cross-chain channel is stuck in a particular sequence. After a Timeout period, the Relayers and Oracle Relayers can request a “SkipSequence” transaction, the stuck sequence will be marked as “Unexecutable”. A corresponding alerts will be raised, and the community has to discuss how to handle this scenario, e.g. payback via the sponsor of the validators, or event clear the fund during next network upgrade. +1. Blocks are produced by a limited set of validators. +2. Validators take turns to produce blocks in a PoA manner, similar to Ethereum's Clique consensus design. +3. Validator set are elected in and out based on a staking-based governance. +4. To enhance network capacity, validators are permitted to produce consecutive blocks within specified parameters. -## Cross-Chain User Experience +### Validator Set -Ideally, users expect to use two parallel chains in the same way as they use one single chain. It requires more aggregated transaction types to be added onto the cross-chain communication to enable this, which will add great complexity, tight coupling, and maintenance burden. Here BC and BSC only implement the basic operations to enable the value flow in the initial launch and leave most of the user experience work to client side UI, such as wallets. E.g. a great wallet may allow users to sell a token directly from BSC onto BC’s DEX order book, in a secure way. +The validator set is the group of nodes that are responsible for validating transactions and producing blocks on the BSC. The validator set is determined by the amount of staking each validator has, which reflects the amount of BNB staked by the validator and its delegators. The top validators with the most staking are selected as the active validator set, and they take turns to propose and vote on blocks. The rest of the validators are in the standby validator set, and they can join the active validator set if their staking increases or if some active validators drop out. -## Cross-Chain Contract Event +Any organization or individual can become part of the validator set by creating their validator on-chain and securing sufficient delegations. Similarly, they can opt-out by simply withdrawing all their BNB delegations. Validators can also be removed from the validator set by slashing, which is a penalty for misbehaving or being offline. -Cross-Chain Contract Event (CCCE) is designed to allow a smart contract to trigger cross-chain transactions, directly through the contract code. This becomes possible based on: +In the genesis stage, a few trusted nodes will run as the initial Validator Set. After the blocking starts, anyone can compete to join as candidates to elect as a validator. -1. Standard system contracts can be provided to serve operations callable by general smart contracts; -2. Standard events can be emitted by the standard contracts; -3. Oracle Relayers can capture the standard events, and trigger the corresponding cross-chain operations; -4. Dedicated, code-managed address (account) can be created on BC and accessed by the contracts on the BSC, here it is named as **“Contract Address on BC” (CAoB)**. +### Validator Election -Several standard operations are implemented: +There are different roles for validators: -1. BSC to BC transfer: this is implemented in the same way as normal BSC to BC transfer, by only triggered via standard contract. The fund can be transferred to any addresses on BC, including the corresponding CAoB of the transfer originating contract. -2. Transfer on BC: this is implemented as a special cross-chain transfer, while the real transfer is from **CAoB** to any other address (even another CAoB). -3. BC to BSC transfer: this is implemented as two-pass cross-chain communication. The first is triggered by the BSC contract and propagated onto BC, and then in the second pass, BC will start a normal BC to BSC cross-chain transfer, from **CAoB** to contract address on BSC. A special note should be paid on that the BSC contract only increases balance upon any transfer coming in on the second pass, and the error handling in the second pass is the same as the normal BC to BSC transfer. -4. IOC (Immediate-Or-Cancel) Trade Out: the primary goal of transferring assets to BC is to trade. This event will instruct to trade a certain amount of an asset in CAoB into another asset as much as possible and transfer out all the results, i.e. the left the source and the traded target tokens of the trade, back to BSC. BC will handle such relayed events by sending an "Immediate-Or-Cancel", i.e. IOC order onto the trading pairs, once the next matching finishes, the result will be relayed back to BSC, which can be in either one or two assets. -5. Auction Trade Out: Such event will instruct BC to send an auction order to trade a certain amount of an asset in **CAoB** into another asset as much as possible and transfer out all the results back to BSC at the end of the auction. Auction function is upcoming on BC. +- **Cabinet:** the top K (which will be 21) validators who get the most chance of producing blocks. +- **Candidate:** the top (K, K+NumOfCandidates]) validators who get a small chance of producing blocks. +- **Inactive:** the rest validators who get no chance of producing blocks. -There are some details for the Trade Out: +![image](./assets/validator-select.png) -1. both can have a limit price (absolute or relative) for the trade; -2. the end result will be written as cross-chain packages to relay back to BSC; -3. cross-chain communication fees may be charged from the asset transferred back to BSC; -4. BSC contract maintains a mirror of the balance and outstanding orders on CAoB. No matter what error happens during the Trade Out, the final status will be propagated back to the originating contract and clear its internal state. +The validator set roles are determined every 24 hours based on the latest staking information. After UTC 00:00, the consensus engine sorts validators and updates the BSC validator set with the ranking information. -With the above features, it simply adds the cross-chain transfer and exchange functions with high liquidity onto all the smart contracts on BSC. It will greatly add the application scenarios on Smart Contract and dApps, and make 1 chain +1 chain > 2 chains. +### System Contracts -# Staking and Governance +There are several built-in contracts (i.e., system contracts) to facilitate the BSC staking and validator election. -Proof of Staked Authority brings in decentralization and community involvement. Its core logic can be summarized as the below. You may see similar ideas from other networks, especially Cosmos and EOS. +- **Validator Set Contract:** The contract periodically elects a validator set. The contract also serves as a vault for temporarily storing validator rewards. -1. Token holders, including the validators, can put their tokens “**bonded**” into the stake. Token holders can **delegate** their tokens onto any validator or validator candidate, to expect it can become an actual validator, and later they can choose a different validator or candidate to **re-delegate** their tokens1. -2. All validator candidates will be ranked by the number of bonded tokens on them, and the top ones will become the real validators. -3. Validators can share (part of) their blocking reward with their delegators. -4. Validators can suffer from “**Slashing**”, a punishment for their bad behaviors, such as double sign and/or instability. -5. There is an “**unbonding period**” for validators and delegators so that the system makes sure the tokens remain bonded when bad behaviors are caught, the responsible will get slashed during this period. +- **System Reward Contract:** This contract acts as a vault to collect part of transaction fees. The funds are used for various public purposes, like distributing fast finality rewards. -## Staking on BC +- **Slash Contract:** This contract is used to keep track of the number of times a validator becomes unavailable and triggers penalties once a certain threshold is reached. Additionally, this contract also handles other types of slash events, such as double signing and malicious voting in fast finality. -Ideally, such staking and reward logic should be built into the blockchain, and automatically executed as the blocking happens. Cosmos Hub, who shares the same Tendermint consensus and libraries with Beacon Chain, works in this way. +- **Stake Hub Contract:** This contract serves as the entry point for managing validators and delegations, while also implementing the logic for slashing specific validators. For delegation/undelegation/redelegation operations, it will call different validators' implementation contracts to manage a user's stake. -BC has been preparing to enable staking logic since the design days. On the other side, as BSC wants to remain compatible with Ethereum as much as possible, it is a great challenge and efforts to implement such logic on it. This is especially true when Ethereum itself may move into a different Proof of Stake consensus protocol in a short (or longer) time. In order to keep the compatibility and reuse the good foundation of BC, the staking logic of BSC is implemented on BC: +### Reward Distribution +The staking reward comes from the transaction fee - when a block is produced, the majority of the block fee will be collected as reward for the validator who proposed the block. -1. The staking token is BNB, as it is a native token on both blockchains anyway -2. The staking, i.e. token bond and delegation actions and records for BSC, happens on BC. -3. The BSC validator set is determined by its staking and delegation logic, via a staking module built on BC for BSC, and propagated every day UTC 00:00 from BC to BSC via Cross-Chain communication. -4. The reward distribution happens on BC around every day UTC 00:00. +Every day, a portion of the rewards collected will be directly sent to the operator account of the validator as commission, while the remaining portion will be sent to the corresponding validator credit contract. And when a user undelegates and claims his/her stakes, the accumulated reward and the original stake will be sent back to him/her. -## Rewarding +## Security and Finality +Given there are more than (N/2+1) validators that are honest, PoA based networks usually work securely and properly. However, there are still cases where certain Byzantine validators may still manage to attack the network, e.g. through the "[Clone Attack](https://arxiv.org/pdf/1902.10244.pdf)". To secure as much as BC, BSC users are encouraged to wait until receiving blocks sealed by more than 2⁄3N+1 different validators. In that way, the BSC can be trusted at a similar security level to BC and can tolerate less than 1⁄3*N Byzantine validators. -Both the validator update and reward distribution happen every day around UTC 00:00. This is to save the cost of frequent staking updates and block reward distribution. This cost can be significant, as the blocking reward is collected on BSC and distributed on BC to BSC validators and delegators. (Please note BC blocking fees will remain rewarding to BC validators only.) +Beside probabilistic finality, BSC proposes a fast finality mechanism to finalize a block, once the block has been finalized, it won't be reverted forever. Its idea is quite similar to [Casper FFG](https://arxiv.org/pdf/1902.10244.pdf). It takes several steps to finalize a block: - A deliberate delay is introduced here to make sure the distribution is fair: +1. A block is proposed by a validator and propagated to other validators. +2. Validators use their BLS private key to sign for the block as a vote message. +3. Gather the votes from validators into a pool. +4. Aggregate the BLS signature if its direct parent block has gotten enough votes when + proposing a new block. +5. Set the aggregated vote attestation into the extra field of the new block's header. +6. Validators and full nodes who received the new block with the direct parent block's + attestation can justify the direct parent block. +7. If two continuous blocks have been justified, then the previous one is finalized. -1. The blocking reward will not be sent to validator right away, instead, they will be distributed and accumulated on a contract; -2. Upon receiving the validator set update into BSC, it will trigger a few cross-chain transfers to transfer the reward to custody addresses on the corresponding validators. The custody addresses are owned by the system so that the reward cannot be spent until the promised distribution to delegators happens. -3. In order to make the synchronization simpler and allocate time to accommodate slashing, the reward for N day will be only distributed in N+2 days. After the delegators get the reward, the left will be transferred to validators’ own reward addresses. +## Governance +BSC introduces the native governance module, drawing inspiration from the OpenZeppelin Governor. Here are the key features of BSC Governance: -## Slashing +- **Proposal and Voting Rights**: Staking credit holders can propose and vote on governance matters. +- **Continuous Rewards**: Voters can keep earning staking rewards during the voting period. +- **Flexible Delegation**: Users can delegate their voting rights, enabling others to participate in governance. +- **Secure Execution**: Proposals undergo a time lock period before execution once passed. -Slashing is part of the on-chain governance, to ensure the malicious or negative behaviors are punished. BSC slash can be submitted by anyone. The transaction submission requires **slash evidence** and cost fees but also brings a larger reward when it is successful. +BNB Chain governance involves a two-step process: **temperature check** and **final decision voting**. The temperature check, typically conducted through the [Snapshot](https://snapshot.org/#/) platform, allows any BNB holder to gauge community sentiment on a proposal. If the proposal receives enough support, it proceeds to the final decision voting phase. This phase often involves on-chain voting by validators or those with staked BNB, and the outcome determines whether the proposal is implemented or rejected. -So far there are two slashable cases. +## Slashing and Penalties +Slashing is a component of on-chain governance that penalizes malicious or negative actions. Anyone can submit a slash transaction on BSC, which involves providing evidence and paying fees. Successful submissions yield significant rewards. Currently, there are three types of slashable cases. ### Double Sign +It is quite a serious error and very likely a deliberate offense when a validator signs more than one block with the same height and parent block. The reference protocol implementation should already have logic to prevent this, so only the malicious code can trigger this. When Double Sign happens, the validator should be removed from the Validator Set right away. -It is quite a serious error and very likely deliberate offense when a validator signs more than one block with the same height and parent block. The reference protocol implementation should already have logic to prevent this, so only the malicious code can trigger this. When Double Sign happens, the validator should be removed from the Validator **Set** right away. - -Anyone can submit a slash request on BC with the evidence of Double Sign of BSC, which should contain the 2 block headers with the same height and parent block, sealed by the offending validator. Upon receiving the evidence, if the BC verifies it to be valid: - -1. The validator will be removed from validator set by an instance BSC validator set update Cross-Chain update; -2. A predefined amount of BNB would be slashed from the **self-delegated** BNB of the validator; Both validator and its delegators will not receive the staking rewards. -3. Part of the slashed BNB will allocate to the submitter’s address, which is a reward and larger than the cost of submitting slash request transaction -4. The rest of the slashed BNB will allocate to the other validators’ custody addresses, and distributed to all delegators in the same way as blocking reward. - -### Inavailability - -The liveness of BSC relies on everyone in the Proof of Staked Authority validator set can produce blocks timely when it is their turn. Validators can miss their turn due to any reason, especially problems in their hardware, software, configuration or network. This instability of the operation will hurt the performance and introduce more indeterministic into the system. - -There can be an internal smart contract responsible for recording the missed blocking metrics of each validator. Once the metrics are above the predefined threshold, the blocking reward for validator will not be relayed to BC for distribution but shared with other better validators. In such a way, the poorly-operating validator should be gradually voted out of the validator set as their delegators will receive less or none reward. If the metrics remain above another higher level of threshold, the validator will be dropped from the rotation, and this will be propagated back to BC, then a predefined amount of BNB would be slashed from the **self-delegated** BNB of the validator. Both validators and delegators will not receive their staking rewards. - -### Governance Parameters - -There are many system parameters to control the behavior of the BSC, e.g. slash amount, cross-chain transfer fees. All these parameters will be determined by BSC Validator Set together through a proposal-vote process based on their staking. Such the process will be carried on BC, and the new parameter values will be picked up by corresponding system contracts via a cross-chain communication. - -# Relayers - -Relayers are responsible to submit Cross-Chain Communication Packages between the two blockchains. Due to the heterogeneous parallel chain structure, two different types of Relayers are created. - -## BSC Relayers - -Relayers for BC to BSC communication referred to as “**BSC Relayers**”, or just simply “Relayers”. Relayer is a standalone process that can be run by anyone, and anywhere, except that Relayers must register themselves onto BSC and deposit a certain refundable amount of BNB. Only relaying requests from the registered Relayers will be accepted by BSC. - -The package they relay will be verified by the on-chain light client on BSC. The successful relay needs to pass enough verification and costs gas fees on BSC, and thus there should be incentive reward to encourage the community to run Relayers. - -### Incentives - -There are two major communication types: - -1. Users triggered Operations, such as `token bind` or `cross chain transfer`. Users must pay additional fee to as relayer reward. The reward will be shared with the relayers who sync the referenced blockchain headers. Besides, the reward won't be paid the relayers' accounts directly. A reward distribution mechanism will be brought in to avoid monopolization. -2. System Synchronization, such as delivering `refund package`(caused by failures of most oracle relayers), special blockchain header synchronization(header contains BC validatorset update), BSC staking package. System reward contract will pay reward to relayers' accounts directly. - -If some Relayers have faster networks and better hardware, they can monopolize all the package relaying and leave no reward to others. Thus fewer participants will join for relaying, which encourages centralization and harms the efficiency and security of the network. Ideally, due to the decentralization and dynamic re-election of BSC validators, one Relayer can hardly be always the first to relay every message. But in order to avoid the monopolization further, the rewarding economy is also specially designed to minimize such chance: - -1. The reward for Relayers will be only distributed in batches, and one batch will cover a number of successful relayed packages. -2. The reward a Relayer can get from a batch distribution is not linearly in proportion to their number of successful relayed packages. Instead, except the first a few relays, the more a Relayer relays during a batch period, the less reward it will collect. - -## Oracle Relayers - -Relayers for BSC to BC communication are using the “Oracle” model, and so-called “**Oracle Relayers**”. Each of the validators must, and only the ones of the validator set, run Oracle Relayers. Each Oracle Relayer watches the blockchain state change. Once it catches Cross-Chain Communication Packages, it will submit to vote for the requests. After Oracle Relayers from ⅔ of the voting power of BC validators vote for the changes, the cross-chain actions will be performed. - -Oracle Replayers should wait for enough blocks to confirm the finality on BSC before submitting and voting for the cross-chain communication packages onto BC. - -The cross-chain fees will be distributed to BC validators together with the normal BC blocking rewards. +Anyone can submit a slash transaction with the evidence of Double Sign to the BSC Slash Contract, which should contain the 2 block headers with the same height and parent block, sealed by the offending validator. Upon receiving the evidence, the contract will verify its validity. -Such oracle type relaying depends on all the validators to support. As all the votes for the cross-chain communication packages are recorded on the blockchain, it is not hard to have a metric system to assess the performance of the Oracle Relayers. The poorest performer may have their rewards clawed back via another Slashing logic introduced in the future. +The validator will be removed from the validator set, a predefined amount of BNB would be slashed from the self-delegated BNB of the validator. -# Outlook +### Malicious Fast Finality Vote +It is also a serious error when a validator signs two fast finality votes with the same target height or the span of one vote including the span of another vote. The reference protocol implementation should already have logic to prevent this, so only the malicious code can trigger this. When **Malicious Vote** happens, the validator should be removed from the Validator Set right away. -It is hard to conclude for BNB Chain, as it has never stopped evolving. The dual-chain strategy is to open the gate for users to take advantage of the fast transferring and trading on one side, and flexible and extendable programming on the other side, but it will be one stop along the development of BNB Chain. Here below are the topics to look into so as to facilitate the community better for more usability and extensibility: +Anyone can submit a slash transaction with the evidence of Malicious Vote to the BSC Slash Contract. Evidence of malicious voting needs to be provided, which includes two conflicting votes and the voting key used for the signature. Upon receiving the evidence, the contract will verify its validity. The validator will be removed from the current set of validators, and the submitter will receive the reward from the system contract. -1. Add different digital asset model for different business use cases -2. Enable more data feed, especially DEX market data, to be communicated from BNB DEX to BSC -3. Provide interface and compatibility to integrate with Ethereum, including its further upgrade, and other blockchain -4. Improve client side experience to manage wallets and use blockchain more conveniently +### Unavailability +The liveness of BSC relies on everyone in the Proof of Staked Authority validator set to produce blocks timely when it is their turn. Validators can miss their turn due to any reason, especially problems in their hardware, software, configuration or network. This instability of the operation will hurt the performance and introduce more indeterministic into the system. +There is an internal smart contract that records the missed blocking metrics of each validator. If the metrics exceed the set threshold, the blocking reward for the validator will not be given to them but shared with other validators performing better. This process aims to gradually remove poorly-operating validators from the set, reducing rewards for their delegators. +If the metrics stay above a higher threshold, the validator will be removed from rotation, and a set amount of BNB will be deducted from their self-delegated BNB. This action results in both validators and delegators not receiving their staking rewards. ------- +## Outlook +It is hard to conclude for the BNB Chain, as it has never stopped evolving. Here below are the topics to look into so as to facilitate the community better for more usability and extensibility: -[1]: BNB business practitioners may provide other benefits for BNB delegators, as they do now for long term BNB holders. +- **Parallel EVM**. Parallel EVM is an extension to the EVM that allows it to execute multiple instructions in parallel, which improves the performance of the network. +- **State Expiry**. Address the problem of increasing world state storage on the BNB Smart Chain, by removing expired storage state. +- **Non-stop Further Decentralization**. +- **Mass Adoption Infra**. The BNB Chain community is committed to making sure +public infrastructure is top-notch and provides foundational building blocks for large scale applications. \ No newline at end of file