支持智能合约的平行币安链
0.1 版本
2020/04/17
币安链于2019 年4月推出主网后，展示了其高速、高吞吐的设计。其主要关注点——原生去中心化应用程序（“dApp”）币安链 DEX（去中心化交易所），经受了在短时间内处理数百万交易量的考验，展示了它的交易引擎的低延迟撮合能力。
灵活性及可用性往往和性能是熊掌与鱼不能兼得。当关注点集中在如何提供一个方便的数字资产发行和交易场所上时，这种设计在某种程度上也带来了限制。 社区呼声最高的一直是最希望看到币安链增加可编程扩展功能，或者直白点说，就是智能合约和虚拟机功能。由于当前币安链的有限功能，数字资产发行者和所有者想要为其资产添加新的去中心化的特性或引入任何形式的社区管理及社区活动时都颇为头痛。
尽管在币安链中添加智能合约功能的期望很高，但这却是个“艰难的决定”。 智能合约的执行可能会减慢DEX的运行速度，并为资产交易添加不确定性因素。即便可以容忍这种妥协，最容易想到的方案可能是基于当前底层的Tendermint共识协议和币安链的主要 RPC接口实现一个虚拟机，但是这种方案会增加现有 dApp 社区的学习成本，不会是一个受欢迎解决方案。
这里我们提出了币安链的并行区块链的概念，以保持原生DEX的高性能，同时友好地支持智能合约功能。
在币安链生态系统中构建两个并行区块链之后，两个区块链将各自运行以提供不同的服务。 新的并行链将被称为“币安智能链”（以下部分简称为**“BSC”），而现有的主网仍然称为“币安链”（以下部分简称为“BC”**）。
BSC的设计遵循以下原则：
-
独立区块链： 从技术上讲，BSC 是一个独立的区块链，而不是Layer 2解决方案。 大多数 BSC 的基础技术和业务功能应该是独立的，这样即使BC短时间停止，BSC也可以运行良好。
-
以太坊兼容： 第一个实用的、被广泛使用的智能合约平台是以太坊 。为了对接相对成熟的应用和社区，BSC 选择与现有的以太坊主网兼容。 这意味着大多数dApp、生态系统组件和工具将与BSC兼容，不需要修改或只需要很小的更改；BSC 节点仅需要类似，或稍高的硬件规范和操作技能就能运作。这一实现应为 BSC 和以太坊未来的版本继续兼容提供空间。
-
基于权益质押的共识和链上管理的：基于权益质押（PoS）的共识更环保，给社区治理提供更灵活的选择。可以预期的是，这种共识会比PoW共识有更好的性能，即出块时间短，交易处理容量高。
-
原生跨链通信： BC 和 BSC 都将原生支持两个区块链之间的跨链通信。 通信协议应该是双向的、去中心化的、无需信任第三方的。 它将专注于在 BC 和 BSC 之间转移数字资产，即 BEP2代币，以及后来引入的其他 BEP代币。 该协议应该不会过于关注存储在区块链其他信息，只有少数情况例外。
基于以上设计原则，BSC的共识协议是为了实现以下目标：
- 出块时间应该比以太坊时间短，例如 5 秒甚至更短。
- 只需要等待有限的时间就能最终确认交易，例如大约 1 分钟或更短。
- 没有通货膨胀，区块链的收益来自手续费，手续费以BNB的形式支付。
- 尽可能与以太坊兼容。
- 配备了基于权益质押的链上治理机制。
尽管工作量证明（PoW）已被证明为实现去中心化网络的实用方案，但它对环境并不友好，而且还需要大量参与者来维护网络安全。
以太坊及一些其他网络，如 MATIC Bor、TOMOChain、GoChain、xDAI在不同的场景中使用权威证明（PoA）或其变体，包括测试网络和主网。PoA 为 51%的攻击提供了防御，更有效的防止一部分拜占庭节点作恶。 选用PoA作为底层共识是理想的选项之一。
同时，PoA 协议因不如PoW去中心化而被批评，因为验证人，即轮流生成块的节点，拥有极大的权力，并且容易产生腐败和遭受安全攻击。 其他区块链, 如 EOS, 引入了不同类型的委托权益证明（DPoS），允许代币持有者投票选举验证人节点。 它让网络更加去中心化，有利于社区管理。
受以上启发，BSC 将 DPoS 和 PoA 结合以达成共识，采用的方案为：
- 区块是由有限数量的验证人生成的
- 验证人轮流以 PoA 方式生成区块，类似于以太坊的Clique共识引擎
- 验证人集合是基于权益质押的链上治理选出和淘汰
在网络启动的创世块阶段，一些受信任的节点将作为初始验证人集合运行。开始出块后，任何人都可以作为候选人参与竞选验证人。 权益质押状态决定前 21 个权益质押最多的节点成为下一个验证人集合，这样的选举和淘汰每 24 小时进行一次。
BNB 是BSC权益质押的通证。
为了保持与以太坊共识协议（包括即将到来的升级）的兼容性，BSC 选择依赖BC 进行权益质押管理（请参阅下面的“权益质押与管理”部分）。 在 BC上有一个专用于BSC权益质押的模块。 它将接受BNB 持有者的BSC权益质押，并计算出权益质押最多节点集。 每次UTC 零时，BC 都会发出一条可校验的 “ValidatorSetUpdate”跨链消息，通知 BSC 更新其验证人集合。
在生成新的区块前，现有的BSC验证人定期检查是否有“ValidatorSetUpdate”消息转发到BSC 。 如果有，它们将在一段高度后（即预定义的区块间隔）之后更新验证人集合。 例如，如果 BSC 每 5 秒生成一个区块且检查周期是 240 个区块，那么当前的验证人集合将在 1200 秒（20 分钟）内检查并更新下一周期的验证人集。
考虑到有超过一半的 ½*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 验证人都将从以BNB 支付的手续费中获得收益。由于 BNB 不是一个会通胀的通证，因此不会像比特币和以太坊网络那样产生挖矿收益，手续费是验证人的主要收益。 由于BNB 也是其他应用的实用型通证，委托人和验证人仍将获得持有BNB 的其他好处。
验证人的收益是从每个区块的交易中收取的手续费获得的。验证人可以决定向质押了BNB 的委托人分享多少收益，以吸引更多的质押投资。 每个验证人将以相同的概率轮流生成区块（如果它们保持 100%在线），因此，从长远来看，所有稳定的验证人都可能获得类似规模的收益。 同时，每个验证人的质押资产大小可能是不同的，因此，这带来了一种与直觉相反的情况，即更多的用户信任并委托质押于同一个验证人，他们可能获得更少收益。因此，只要验证人仍然是可信的（不受信任的验证人可能带来极大的风险），理性的委托人就会倾向于委派抵押数量较低的验证人。 最终，所有验证人的区别都会更小。这实际上将防止其他网络上出现的质押集中和“赢家永远赢”的问题。
手续费的一部分也将奖励给跨链通信的中继器。 请参考下面的“中继器”部分。
BNB 和 BEP2代币可以在BC和BSC上同时流通。由此定义了：
- 同一代币可以在两个网络上流通，并且通过跨链通信机制双向地在它们之间流通。
- 同一代币的总发行量由两个网络共同决定，即代币的总有效供应量应该是代币在BSC和BC上的发行量的总和。
- 代币可以最初在BSC上创建，格式类似于 ERC20，然后在BC上创建为BEP2，相反的顺序创建也可以。 在这两个网络上都有原生方式来连接这两个网络，并确保代币的总发行量一致。
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的典型过程如下：
- 确保在两条链上的 BEP2 代币和 BEP2E代币具有相同的总供应量。与更典型的ERC20合约 相比，BEP2E必须添加以下有3 种函数：
- symbol()： 获取代币符号
- decimals()： 获取代币十进制小数位数
- getOwner()： 获取绑定合约所有者的地址。这个值应该在 BEP2E合约构造函数中初始化，以便绑定操作可以进一步验证绑定消息是否得到来自 BEP2E的发行者。
-
确定两个区块链的初始发行量。假设总供应量为S，并且 BC 上的预期初始循环供应量为 K，那么所有者应该将 S-K 个代币锁定到 BC上的系统控制地址。
-
同样，K个代币被锁定在BSC上的特殊合约中，由一个叫做TokenHub的合约控制绑定相关功能。BEP2E代币的发行者应该将该代币的K个锁定到TokenHub，从而使S- K个代币在BSC上流通。因此，两个区块链之间的总流通量仍然是S*。
-
BEP2 代币的发行者在BC 上发送绑定交易。经过适当的验证后，一旦交易成功执行：
-
它将 S-K 个代币转账到BC 上的系统控制地址。
-
将创建一个跨链绑定请求包，等待中继传递消息。
-
BSC 中继将把跨链绑定请求包中继到 BSC 上的 TokenHub 中，相应的请求和信息将存储在合约中。
-
合约所有者（且只有该所有者）可以运行TokenHub合约的特殊方法ApproveBind来验证绑定请求，以将其标记为成功状态。它将验证：
- 代币未被绑定；
- 绑定具备正确的代币名称，并具有正确的总供应量和位数信息；
- 在两个网络上正确完成锁定；
- 一旦
ApproveBind方法成功，TokenHub将标记这两种代币是绑定的，并且在 BSC 上共享同一总流通量，并且状态将传回 BC。在经过BC的最终确认后，BEP2E合约地址和小数点位数将作为一个新属性写入BEP2代币上，代币就可以双向地在两个区块链之间进行转账。 如果 ApproveBind 失败，则故障事件也将传输回BC 以释放锁定的代币，并且可以在以后重试上述步骤。
跨链通信是让社区利用双链结构的关键基础架构：
- 用户可以随意在BSC 或BC上创建任何代币化的金融产品和数字资产；
- 在 BSC上的代币可以在BC上稳定的，高吞吐，极快速和友好的环境中完成程序化交易和资产流通；
- 用户可以在统一的工具生态系统和用户界面中完成这些操作。
跨链转账是两个区块链之间通信的关键。 它的逻辑是：
- 转出的区块链将把来自源地址持有的金额锁定到系统控制的地址/合约中；
- 转入区块链将解锁系统控制的地址/合约中的金额，并将其转账到目标地址。
跨链转账包消息应允许BSC中继器和BC Oracle中继器验证以下信息：
- 从源地址中锁定了足够数量的代币资产到源区块链上的系统控制地址/合约中。 这可以在目标区块链上得到证实。
- 适当的代币资产额从系统控制的地址/合约中释放，并分配到目标区块链上的目标地址中。 如果失败，可以在源区块链上确认，这样锁定的代币就可以被释放回去（可能会扣除费用）。
- 无论转账是否成功，在此转账操作完成后，两个区块链上代币资产的流通总量都不会改变。
跨链通信的体系结构如上图所示。 为了适应两个异构系统，通信处理在每个方向上都是不同的。
BC 是一个基于 Tendermint 的、具有即时完成确认的区块链。需要至少2/3* N + 1 总投票权的验证人对每个区块签名。 因此可以通过区块头和 Merkle 证明验证来验证区块交易甚至状态值是可行的。这一设计已经被研究并实现为“轻客户端协议”。它被以太坊社区广泛讨论，也被用于实现Cosmos的跨链通信协议。 从BC到BSC 通信将在通过 BSC 智能合约实现的**“链上轻客户端”中得到验证（其中一些是“预编译”合约）。在 BC 上发生一些交易和状态更改之后，如果一个交易触发跨链通信，则中继器将创建并传递跨链 “数据包”**消息，并作为数据提交到 BSC 的“轻客户端合约”上。轻客户端合约将验证跨链数据包，并在通过验证后执行交易。这类验证是通过下述设计保证：
- BC的区块状态将通过区块头和pre-commits同步到BSC上的轻客户端合约，以获得以下信息：
- 验证人签名的 BC 区块和app哈希
- 当前验证人集合和验证人集合更新
- 存储于BC区块链状态中的“键-值”对将根据 Merkle 证明和上面的信息进行验证。 在确认键-值对准确和可信之后，轻客户端合约将执行与跨链包对应的操作。 BC到BSC的跨链操作可以创建如下数据包：
- 绑定：将BEP2代币与 BEP2E绑定
- 转账：绑定后进行跨链转账，这意味着BC上的流通将会由于锁定减少，并出现在BSC上的目标地址中，保证总流通量不变
- 错误处理：处理 BSC到BC 通信的任何超时/失败事件
- BSC验证人集合更新
为了确保没有重复、消息序列正确和超时处理，BC 引入了**“通道”**概念来管理跨链通信。 对于中继器，请参考下面的“中继器”部分。
BSC 使用了PoSA(基于权益质押的权威证明)共识协议，该协议可能会出现分叉，因此要求对更多的区块进行确认。一个区块只有一个验证人的签名，因此仅依赖一个区块不适合验证来自 BSC的数据。 为了充分利用 BC的验证人集合信息，采用了类似于桥接或 Oracle 区块链的思路：
- 来自BSC的跨链通信请求将作为交易提交并在BSC上执行。交易的执行将发出事件，这类事件可以被观察到，并打包成“Oracle”，发送到BC上。 这种类型的“Oracle”交易包没有区块头哈希和 Merkle 证明，而是直接包含操作的跨链信息，如发送方、接收方和要转账的金额。
- 为了保证 Oracle 的安全性，BC 的验证人将组建一组“Oracle 中继器”。 BC 的每个验证人都应独立运作一个 Oracle 中继器。这些Oracle 中继器将使用和BC验证人节点相同的秘钥签名、提交和投票给 BC 的跨链通信包。 任何由超过⅔*N+1个Oracle中继器 的投票权限签名的交易包，其安全性与由 ⅔*N+1 相同法定数量的验证人的投票权限签名的区块相同。
通过复用同样的验证人集合， BC 无需实现一个轻客户端，并在 BC 上持续更新区块。这样的Oracle也有 Oracle ID 和类型，以确保顺序和正确的错误处理。
在某些情况下，跨链通信会失败。 例如，由于合约中的一些编码错误，在 BSC 上无法执行中继数据包。 在这种场景中使用超时和错误处理逻辑。 对于可识别的用户和系统错误或任何预期的异常情况，这两个网络应该自行修复。例如，当 BC 到 BSC的转账失败时，BSC 将发出一个失败事件，Oracle 中继器将在BC 上执行退款；当 BSC 到 BC 的转账失败时，BC 将发出一个退款包给BSC中继器，以便解锁款项。 然而，跨链通信的任何步骤都可能发生意外错误或异常。在这种情况下，BSC中继器和Oracle 中继器将发现相应的跨链通道被卡在一个特定的序列中。超时一段时间后，BSC中继器和 Oracle 中继器可以请求“SkipSequence”交易，卡住的序列将被标记为“不可执行”。 将提出相应的警告，社区必须讨论如何处理这种情况，例如通过验证人进行赔付，或者甚至在下一次网络升级期间清理错误锁定的资金。
理想情况下，用户希望使用两条平行链的方式与使用一条单链的方式相同。它需要将更多复合交易类型添加到跨链通信中以支持这一点，这将极大地增加复杂性、紧耦合和维护负担。在这里，BC和BSC只实现了基本的操作，以在初始启动时促成价值流动，并将大部分用户体验工作通过客户端实现，如钱包。例如，一个钱包可以让用户将代币直接从BSC发送订单到BC的DEX，以一种安全可靠的方式卖出代币。
跨链合约事件（CCCE）是为了允许智能合约直接通过合约代码触发跨链事件而设计的。 这在下列基础上成为可能：
- 可以提供标准的系统合约，以服务于一般智能合约可调用的操作；
- 标准事件可以由标准合约发出；
- Oracle 中继器可以捕获标准事件，并触发相应的跨链操作；
- 可以在 BC 上创建专用的、代码管理的地址，并由 BSC 合约访问，这里它被命名为 “BC的合约地址”（CAoB）。
以下几个典型的标准功能将会被实现：
实现以下标准操作：
- BSC 到BC的转账： 这与普通的 BSC 到 BC 转账一样，都是通过标准合约触发的。 资金可以转账到 BC 上的任何地址，包括转账给原始合约中相应 CAoB 。
- BC内转账： 转账的完成被视为为一个特殊的跨链转账，而真正的转账是从 CAoB 到任何其他地址（甚至是另一个 CAoB）。
- BC 到BSC 转换： 这是以双通跨链通信的方式实现的。 第一个通道是由 BSC合约触发并传输到 BC 上，然后在第二个通道中，BC 将启动一个正常的 从BC 到 BSC的跨链转账，转账地址为 CAoB 到 BSC上的合约地址。需要特别注意的是，BSC 合约只在第二个通道转账时增加余额，第二个通道转账中的错误处理与正常的 BC 到 BSC 转账相同。
- IOC（立即执行或取消）交易： 将资产转移到BC 的主要目的是交易。该事件将指示将CAoB中某一资产交易为另一资产，并转移交易的剩余的目标代币，并将全部结果转账给BSC。BC将通过发送“IOC”订单来处理此类中继事件，如IOC订单发到交易对上，一旦下一次撮合完成，执行结果将被传送回BSC，其可以是一种资产，也可以是两种资产。
- 拍卖交易：这样的活动将指示BC发出拍卖交易，将CAoB中一定数额的资产尽可能多地转换成另一项资产，并在拍卖结束时将所有成果转回BSC。拍卖功能即将在BC上线。
以下是交易的一些细节：
a. 针对交易，双方都可以有一个（绝对或相对的）价格限制； b. 最终结果将以跨链交易包的形式写入 BSC； c. 跨链通信费用可从转回 BSC 的资产中收取； d. BSC 合约反映了 CAoB 的余额和未完成的订单。 无论在交易期间发生什么错误，最终状态都将被传输回原始合约并清算其内部状态。
在上述特点的基础上，将具有高流动性的跨链转账和交易功能非常方便地添加到 BSC 的所有智能合约中。 它将极大地增加在智能合约 和 dApps 上的应用场景，使币安双链产生1+1>2的聚合效应。
PoSA实现了去中心化式的社区治理。 你可以从其他网络中看到类似的想法，特别是 Cosmos 和 EOS 。 其核心逻辑可概括如下。
- 代币持有者，包括验证人，可以将他们的代币 “锁定”到权益质押中。 代币持有者可以将他们的代币委托给任何验证人或一个验证人候选对象。 之后他们还可以重新选择不同的验证人或候选对象来对他们的代币进行委托。
- 所有验证人候选对象都将按其获得委托代币的数量进行排序，排名前列的将成为真正的验证人。
- 验证人可以与它们的委托人共享区块收益。
- 验证人可能会遭受**“罚息”**，即对他们的不良行为的惩罚，如双重签名和/或不稳定性。 这样的损失也会与他们的委托人共同分担。
- 验证人和委托人有一个 “解除绑定期”。当发现恶意拜占庭行为时，代币仍然在一定时间内保持锁定，作恶人将被及时惩罚。
理想情况下，这样的权益质押和奖励发放逻辑应该包含在区块链中，并在产生新区块时自动执行。与币安链一样采用Tendermint共识库的Cosmos Hub就是这样工作的。
自设计之日起，BC就一直在准备启用PoS。另一方面，BSC想要尽可能地与以太坊保持兼容，在其上直接实现PoSA是一个巨大的挑战和压力。特别是考虑到以太坊本身可能在短时间（或更长时间）内迁移到PoS共识协议时，尤其如此。为了保持以太坊的兼容性和复用BC的基础架构，我们在BC上完成了BSC的权益质押逻辑：
- 质押代币是 BNB，这是因为它是两个区块链上的原生代币。
- 在BC上记录BSC的权益质押和委托行为。
- BSC 验证人集由它的权益质押和委托逻辑来决定，在BC上构建一个BSC的权益质押模块，并通过跨链通信在每天UTC 00:00:00 由BC传送到 BSC 。
- BC上的奖励分配发生在每天UTC 00:00时刻。
验证人集更新和奖励分配都发生在每天 的UTC 00:00 。这是为了节省频繁更新和区块奖励分配的成本。频繁分配奖励的代价可能是巨大的，因为区块奖励是在BSC上收取的，并在BC上分发给BSC验证人和委托人。（请注意，BC出块奖励仅分发给BC验证人。）
为了确保分配是公平的，这里引入了一种延后分配的算法：
- 区块奖励不会立即发送给验证人，而是计算并积累在智能合约中；
- 当BSC收到验证人集更新消息时，它将触发跨链转账，将奖励转账给验证人的托管地址。 托管地址是由系统控制，因此在向委派者承诺的分配完成之前，奖金是不能用的。
- 为了使同步更简单，并分配时间以防出现罚没，第T天的奖励将在第T + 2 天分配。 在委托人收到奖励后，剩下的收益将被转移到验证人自己的奖励地址。
罚息是链上管理的一部分，以确保恶意或负面行为受到惩罚。 BSC罚息证据可以由任何人提交。 交易提交要求提交罚息证据和缴纳手续费，但一旦成功提交，也带来了更多奖励。
到目前为止，有两种可以被惩罚的情况。
双重签名
当验证人故意签署多个相同高度并具有相同父块的区块时，这是很严重的作恶行为。 协议的实现应该已经考虑到如何防止这种情况发生，因此只有恶意代码才能触发这种情况。当出现双重签名时，验证人应该立即从验证人集合中移除。
任何人都可以在 BC 上提交带有 BSC 双重签名的罚息请求，应该包含两个具有相同高度的区块头和母区块，以及违规验证人的签名。 在收到证据后，如果 BC 确认该证据是有效的：
- 该验证人将立刻发送 BSC “验证人集合更新”跨链消息，恶意验证人将从验证集中剔除；
- 验证人的权益质押将按照预先设定的金额进行惩罚；
- 一部分被惩罚的BNB 将奖励给证据提交者。奖励金额应远远大于提交罚息请求事件的成本
- 剩下的 BNB 将分配给其他验证人的托管地址，并以与区块奖励相同的方式分配给所有委托人。
不稳定性
BSC 的可用性依赖于PoSA共识中验证人集合中的每个验证人，当轮到其出块时，他们能够及时生成区块。 验证人可能由于一些原因而错过出块时机，特别是由于硬件、软件、配置或网络方面的问题。 这种不稳定运行将损害网络的性能，并给系统带来更多的不确定性。
BSC有一个内部的合约，负责记录每个验证人错过的区块。 一旦该指标超过预定义的阈值，验证人的区块奖励将不会被转移到 BC 进行分发，而是被其他更好的验证人共享。通过这种方式，运行不良的验证人会逐渐退出，因为它们的委托人将获得较少奖励或没有奖励。如果该数据仍然高于另一个较高的阈值级别，验证人将受到惩罚，并将传输回BC，在BC中，验证人的的抵押资产将被罚没一部分。
参数管理
有许多系统参数来控制 BSC 的行为，如罚息阈值和数量，跨链转账费用等。所有这些参数将由 BSC 验证人通过提案投票过程确定。此过程将在 BC 上进行，系统合约将通过跨链通信来获取最新参数。
中继器负责提交两个区块链之间的跨链通信包。 由于并联链结构的异构性，产生了两种不同类型的中继器。
BC 到 BSC 通信的中继器称为 “BSC 中继器”，或简称为 “中继器”。 中继器是一个独立的进程，任何人都可以在任何地方运行，但是中继器必须在BSC 注册并锁定一定数量的 BNB 。 BSC将只接受来自已注册的中继器的中继请求。
它们所传递的数据包将由 BSC 上的链上轻客户端进行验证。中继成功需要通过足够的验证，并在BSC上支付足够的手续费，因此，应该有激励性奖励来鼓励社区经营中继器。
有两种主要的沟通方式：
- 客户端操作，如跨链绑定、转账和错误处理等。 这应该由事件请求者支付。
- 系统同步，例如传递“退回资金”数据包（由于大多数Oracle中继失败造成的），或者用于验证的区块头，以及验证人集合更新。以上奖励由 BSC 系统合约支付。
如果某些中继器有更快的网络和更好的硬件，它们可以垄断所有的中继包，而不会给其他中继器留下任何收益。 因此，将有更少的参与者加入中继，这将鼓励集中化，但损害网络的效率和安全。 理想情况下，由于 BSC 验证人的分散化和动态重新选择，一个中继器不可能总是第一个传递每个消息。 但是为了避免进一步的垄断，奖励经济机制也是专门为尽量减少这种机会而设计的：
- 对中继器的奖励将只分批次发放，而一次发放将覆盖多个成功的中继器包。
- 一个中继器可以从批处理分发中获得的报酬与成功中继包的数量并不是成比例的。 相反，除了前几个数据包，在一个批次期间中继器传递传递数据包越多，它将获得的报酬越少。
BSC 到 BC 通信的中继器使用 “Oracle”模型，也就是所谓的 “Oracle 中继器”。 每个BC验证人都必须（只有验证集合中的验证人可以）运行 Oracle 中继器。 每个 Oracle 中继器都会观察 BSC状态的变化。 一旦它捕获到跨链通信包，它将提交投票请求。在获得大于2/3投票支持更改之后，将执行跨链操作。
Oracle 中继器应该等待足够的区块来确认 BSC 的最终结果，然后才向 BC 提交和投票跨链通信包。
跨链费用将与正常的 BC 区块奖励一起分配给 BC 验证人。
此种 Oracle中继器依赖于所有验证人的支持。 由于跨链通信包的所有投票都记录在区块链上，因此评估 Oracle 中继器的性能并不难。将来可能会通过引入的另一种惩罚机制来限制表现最差的验证人的收益。
对于币安链的未来，很难做出一个定论，因为它从未停止进化。双链策略一方面为用户打开了灵活可扩展的编程之门，另一方面为用户保留了极速交易合转账的便利，但这只是币安链发展的一个阶段。以下是一些值得关注的主题，以促进社区更好地获得更多的可用性和可扩展性：
1.为不同的业务用例添加不同的数字资产模型 2.实现将更多的数据源，特别是 DEX 市场数据，从币安 DEX传输到BSC 3.提供兼容以太坊及其未来升级，以及其他区块链的接口 4.改进钱包和区块链客户端的可用性