├── BNB智能链.md ├── README.md ├── WHITEPAPER.md ├── assets ├── cross-chain.png └── validator-select.png └── translations ├── PUTINGPAPEL.md └── Whitepaper_ BNB Smart Chain_spanish_translation_VIOLA.md /BNB智能链.md: -------------------------------------------------------------------------------- 1 | # BNB 智能链 2 | 3 | ## 目录 4 | 5 | - [BNB 智能链](#BNB-智能链) 6 | - [动机](#动机) 7 | - [BNB 链的演进](#BNB链的演进) 8 | - [设计原则](#设计原则) 9 | - [代币经济](#代币经济) 10 | - [原生代币](#原生代币) 11 | - [种子基金](#种子基金) 12 | - [实时销毁](#实时销毁) 13 | - [共识和验证人法定人数](#共识和验证人法定人数) 14 | - [质押权威证明](#质押权威证明) 15 | - [验证人集合](#验证人集合) 16 | - [验证人选举](#验证人选举) 17 | - [系统合约](#系统合约) 18 | - [奖励分配](#奖励分配) 19 | - [安全性和最终性](#安全性和最终性) 20 | - [治理](#治理) 21 | - [惩罚和处罚](#惩罚和处罚) 22 | - [双重签名](#双重签名) 23 | - [恶意快速最终性投票](#恶意快速最终性投票) 24 | - [不可用性](#不可用性) 25 | - [展望](#展望) 26 | 27 | ## 动机 28 | 29 | 自2019年4月主网社区启动以来，信标链展示了其高速和大吞吐量的设计。信标链的主要焦点是支持一个原生的、低延迟、高性能的去中心化交易所。其中最受欢迎的功能之一是可编程的可扩展性，特别是智能合约和虚拟机功能的实现。为了满足这一需求，我们提出了与信标链并行运行的BNB智能链，以促进一个用户友好的智能合约环境。 30 | 31 | BNB智能链（BSC）是一个与EVM兼容的区块链，旨在为BNB链生态系统带来可编程性和互操作性。作为更广泛的BNB链的一部分，BSC旨在为去中心化应用（dApps）和数字资产提供高吞吐量、低延迟和低成本的环境。本白皮书概述了BSC的架构、机制和演进历程。虽然已经过去几年，我们仍然保留这份文件，因为它继续作为一个有用的参考，并准确地代表BNB智能链。 32 | 33 | ## BNB链的演进 34 | 35 | - **初始启动和信标链。** 信标链于2019年4月启动，旨在支持BNB DEX，具备快速交易和大吞吐量的特性。然而，其缺乏可编程性和智能合约功能对开发者和用户造成了限制。 36 | 37 | - **BNB智能链的引入。** 为了解决这些限制，BNB智能链于2020年引入，利用并行区块链架构支持智能合约，同时保持DEX的高性能。 38 | 39 | - **BNB链融合。** 2023年11月，BNB链融合提案（[BEP-333](https://github.com/binance-chain/BEPs/blob/master/BEP333.md)）标志着一个重大转变。这个提案概述了信标链的终结，将其功能与BSC合并，创建一个统一的高性能区块链网络。这次融合旨在简化操作，增强安全性，并简化BSC上的用户体验。 40 | 41 | - **opBNB。** 于2023年推出，opBNB是一个基于Optimism OP Stack的以太坊虚拟机（EVM）兼容的Layer 2链。它旨在通过提供更低的gas费用和高性能区块链技术来革新区块链行业。 42 | 43 | - **BNB Greenfield。** Greenfield是一个新颖的去中心化数据存储网络，与BNB智能链（BSC）有原生桥接，管理用户权限、存储桶创建和文件删除，从而改变用户与其数据交互的方式。 44 | 45 | BNB链是一个不断发展的生态系统，BSC是其核心。作为一个关键的金融系统，BSC承载着最多的加密资产价值。它还作为opBNB和其他Layer 2解决方案的结算和数据可用性层，确保layer2的安全性。此外，BSC作为Greenfield的智能合约编程平台，促进Greenfield内的数据交换和流通。 46 | 47 | BSC从最初的双链架构（其中质押、验证和治理委托给信标链）发展到现在，经历了显著的演变。在BNB链融合之后，BSC经历了实质性的架构变更，最终成为一个完全独立的区块链。 48 | 49 | ## 设计原则 50 | 51 | 以下是BSC的设计原则： 52 | 53 | 1. **独立区块链：** 从技术上讲，BSC是一个独立的区块链，而不是一个layer-2解决方案。BSC的大多数基本技术和业务功能应该是自驱动的。 54 | 55 | 2. **以太坊兼容性：** 以太坊是第一个实用且广泛使用的智能合约平台。为了利用相对成熟的应用和社区，BSC选择与现有的以太坊主网兼容。这意味着大多数dApps、生态系统组件和工具无需或只需最小的更改就能与BSC一起工作；BSC节点将需要类似（或稍高）的硬件规格和技能来运行和操作。BSC的实现具备跟上以太坊的进一步升级的能力。 56 | 57 | 3. **涉及质押的共识和治理：** 基于质押的共识更加环保，并为社区治理留下更灵活的选择。预期这种共识应能实现比[工作量证明](https://en.wikipedia.org/wiki/Proof_of_work)区块链系统更好的网络性能，即更快的出块时间和更高的交易容量。 58 | 59 | 4. **快速出块时间和快速最终性：** BSC将实施快速最终性机制，允许在正常情况下在两个区块确认内完成区块最终性。这一特性，结合BSC 3秒的快速出块时间，提供了近乎即时的交易最终性和良好的用户体验。 60 | 61 | ## 代币经济 62 | 63 | BSC、opBNB和Greenfield共享BNB这一统一代币。这定义了： 64 | 65 | 1. BNB可以在所有网络上流通，并通过跨链通信机制流动。 66 | 2. BNB的总流通量应在三个网络中管理，即BNB的总有效供应量应是所有网络中代币总有效供应量的总和。 67 | 68 | ### 原生代币 69 | 70 | BNB将在BSC上运行，就像ETH在以太坊上运行一样，因此它仍然是BSC的"原生代币"。这意味着BNB将用于： 71 | 72 | 1. 支付在BSC上部署智能合约的"费用"。 73 | 2. 在选定的BSC验证人上进行质押，并获得相应的奖励。 74 | 3. 执行跨链操作，如在BSC、opBNB和Greenfield之间转移代币资产。 75 | 76 | ### 种子基金 77 | 78 | 在BSC的创世阶段，一定数量的BNB将在信标链上销毁，并在BSC上铸造。这个数量被称为"种子基金"，在第一个区块后在BSC上流通以分配给在创世时引入的初始验证人集合。 79 | 80 | ### 实时销毁 81 | 82 | 为了加速BNB的销毁过程并使BSC更加去中心化，部分gas费将被销毁。每个区块中，验证人收集的gas费的固定比例将被销毁。销毁比例可由BSC验证人治理设置。 83 | 84 | ## 共识和验证人法定人数 85 | 86 | 基于上述设计原则，BSC的共识协议旨在实现以下目标： 87 | 88 | 1. 出块时间应比以太坊网络更短，例如3秒。 89 | 2. 确认交易最终性需要有限的时间，例如大约10秒级或更短。 90 | 3. 原生代币BNB没有通胀：区块奖励从交易费中收集，并将以BNB支付。 91 | 4. 尽可能与以太坊系统兼容。 92 | 5. 允许权益证明区块链网络治理。 93 | 94 | ### 质押权威证明 95 | 96 | 尽管[工作量证明（PoW）](https://en.wikipedia.org/wiki/Proof_of_work)被认为是实现去中心化网络的实用机制，但它对环境不友好，而且还需要大量参与者来维护安全性。 97 | 98 | 以太坊和一些其他区块链网络，如MATIC Bor、TOMOChain、GoChain、xDAI，在不同场景中使用[权威证明（PoA）](https://en.wikipedia.org/wiki/Proof_of_authority)或其变体，包括测试网和主网。PoA提供了对51%攻击的一些防御，提高了效率，并对某些程度的拜占庭参与者（恶意或被黑客入侵）具有容忍度。 99 | 100 | 同时，PoA协议最受批评的是不如PoW去中心化，因为验证人（即轮流产生区块的节点）拥有所有权力，容易受到腐败和安全攻击。其他区块链，如EOS和Lisk，引入了不同类型的[委托权益证明（DPoS）](https://en.wikipedia.org/wiki/Delegated_proof_of_stake)，允许代币持有者投票选举验证人集合。这增加了去中心化程度，有利于社区治理。 101 | 102 | BSC在这里提议将DPoS和PoA结合用于共识，以便： 103 | 104 | 1. 区块由有限的验证人集合产生。 105 | 2. 验证人以PoA方式轮流产生区块，类似于以太坊的Clique共识设计。 106 | 3. 验证人集合基于基于质押的治理进行选举和退出。 107 | 4. 为了增强网络容量，允许验证人在指定参数内产生连续区块。 108 | 109 | ### 验证人集合 110 | 111 | 验证人集合是负责验证交易和在BSC上产生区块的节点组。验证人集合由每个验证人的质押量决定，这反映了验证人及其委托人质押的BNB数量。拥有最多质押的顶级验证人被选为活跃验证人集合，他们轮流提议和投票区块。其余的验证人在备用验证人集合中，如果他们的质押增加或某些活跃验证人退出，他们可以加入活跃验证人集合。 112 | 113 | 任何组织或个人都可以通过在链上创建他们的验证人并获得足够的委托来成为验证人集合的一部分。同样，他们也可以通过简单地撤回所有BNB委托来选择退出。验证人也可能因为行为不当或离线而被惩罚（slashing）从验证人集合中移除。 114 | 115 | 在创世阶段，一些受信任的节点将作为初始验证人集合运行。在区块开始产生后，任何人都可以竞争加入成为候选人，以当选为验证人。 116 | 117 | ### 验证人选举 118 | 119 | 验证人有不同的角色： 120 | 121 | - **内阁：** 前K个（将是21个）获得最多出块机会的验证人。 122 | - **候选人：** 前(K, K+NumOfCandidates]个获得少量出块机会的验证人。 123 | - **非活跃：** 其余没有出块机会的验证人。 124 | 125 | ![image](./assets/validator-select.png) 126 | 127 | 验证人集合角色每24小时根据最新的质押信息确定一次。在UTC 00:00之后，共识引擎对验证人进行排序，并用排名信息更新BSC验证人集合。 128 | 129 | ### 系统合约 130 | 131 | 有几个内置合约（即系统合约）来促进BSC的质押和验证人选举。 132 | 133 | - **验证人集合合约：** 该合约定期选举验证人集合。该合约还作为临时存储验证人奖励的保险库。 134 | 135 | - **系统奖励合约：** 此合约作为收集部分交易费用的保险库。这些资金用于各种公共目的，如分发快速最终性奖励。 136 | 137 | - **惩罚合约：** 此合约用于跟踪验证人变得不可用的次数，并在达到某个阈值时触发惩罚。此外，该合约还处理其他类型的惩罚事件，如双重签名和快速最终性中的恶意投票。 138 | 139 | - **质押中心合约：** 此合约作为管理验证人和委托的入口点，同时实现惩罚特定验证人的逻辑。对于委托/解除委托/重新委托操作，它将调用不同验证人的实现合约来管理用户的质押。 140 | 141 | ### 奖励分配 142 | 质押奖励来自交易费用 - 当一个区块被产生时，大部分区块费用将作为奖励收集给提议该区块的验证人。 143 | 144 | 每天，收集的奖励的一部分将直接作为佣金发送到验证人的操作员账户，而剩余部分将发送到相应的验证人信用合约。当用户解除委托并申领其质押时，累积的奖励和原始质押将返还给他/她。 145 | 146 | ## 安全性和最终性 147 | 假设有超过(N/2+1)的验证人是诚实的，基于PoA的网络通常能安全且正常工作。然而，仍有某些拜占庭验证人可能设法攻击网络的情况，例如通过"[克隆攻击](https://arxiv.org/pdf/1902.10244.pdf)"。为了确保与BC一样安全，建议BSC用户等待接收到超过2⁄3N+1个不同验证人密封的区块。这样，BSC可以被信任到与BC类似的安全级别，并且可以容忍少于1⁄3*N的拜占庭验证人。 148 | 149 | 除了概率性最终性，BSC提出了一种快速最终性机制来最终确定一个区块，一旦区块被最终确定，它将永远不会被回滚。其想法与[Casper FFG](https://arxiv.org/pdf/1902.10244.pdf)非常相似。最终确定一个区块需要几个步骤： 150 | 151 | 1. 一个区块由一个验证人提议并传播给其他验证人。 152 | 2. 验证人使用他们的BLS私钥为区块签名作为投票消息。 153 | 3. 将验证人的投票收集到一个池中。 154 | 4. 在提议新区块时，如果其直接父区块已获得足够的投票，则聚合BLS签名。 155 | 5. 将聚合的投票证明设置到新区块头的额外字段中。 156 | 6. 接收到带有直接父区块证明的新区块的验证人和全节点可以证明直接父区块。 157 | 7. 如果两个连续的区块都被证明，那么前一个区块就被最终确定。 158 | 159 | ## 治理 160 | BSC引入了原生治理模块，灵感来自OpenZeppelin Governor。以下是BSC治理的主要特点： 161 | 162 | - **提案和投票权**：质押token持有者可以提出和投票决定治理事务。 163 | - **持续奖励**：投票者在投票期间可以继续获得质押奖励。 164 | - **灵活委托**：用户可以委托他们的投票权，使其他人能够参与治理。 165 | - **安全执行**：提案一旦通过，在执行前会经过一个时间锁定期。 166 | 167 | BNB Chain的治理涉及两个步骤：**热点测试**和**最终决策投票**。热点测试通常通过[Snapshot](https://snapshot.org/#/)平台进行，允许任何BNB持有者评估社区对提案是否感兴趣。如果提案获得足够的支持，它将进入最终决策投票阶段。这个阶段通常涉及验证者或那些质押了BNB的人进行链上投票，结果决定提案是否被实施或拒绝。 168 | 169 | ## 惩罚和处罚 170 | 惩罚是链上治理的一个组成部分，用于惩罚恶意或负面行为。任何人都可以在BSC上提交惩罚交易，这涉及提供证据和惩罚作恶者。成功的提交将获得可观的奖励。目前，有三种可惩罚的情况。 171 | 172 | ### 双重签名 173 | 当一个验证者为具有相同高度和父区块的多个区块签名时，这是一个相当严重的错误，很可能是故意的违规行为。参考协议实现应该已经有逻辑来防止这种情况，所以只有恶意代码才能触发这种情况。当发生双重签名时，验证者应立即从验证者集合中移除。 174 | 175 | 任何人都可以向BSC惩罚合约提交带有双重签名证据的惩罚交易，该证据应包含由违规验证者封存的具有相同高度和父区块的两个区块头。在收到证据后，合约将验证其有效性。 176 | 177 | 验证者将从验证者集合中移除，预定数量的BNB将从验证者的自委托BNB中扣除。 178 | 179 | ### 恶意快速最终性投票 180 | 当验证者为具有相同目标高度的两个快速最终性投票签名，或者一个投票的范围包含另一个投票的范围时，这也是一个严重的错误。参考协议实现应该已经有逻辑来防止这种情况，所以只有恶意代码才能触发这种情况。当发生**恶意投票**时，验证者应立即从验证者集合中移除。 181 | 182 | 任何人都可以向BSC惩罚合约提交带有恶意投票证据的惩罚交易。需要提供恶意投票的证据，包括两个冲突的投票和用于签名的投票公钥。在收到证据后，合约将验证其有效性。验证者将从当前验证者集合中移除，提交者将从系统合约获得奖励。 183 | 184 | ### 不可用性 185 | BSC的活跃性依赖于权益证明授权验证者集合中的每个人在轮到他们时及时产生区块。验证者可能因为任何原因错过他们的回合，特别是硬件、软件、配置或网络问题。这种操作的不稳定性将损害性能并给系统引入更多的不确定性。 186 | 187 | BSC有一个内部智能合约记录每个验证者的错过区块数量。如果这个指标超过设定的阈值，验证者的区块奖励将不会给予他们，而是与表现更好的其他验证者共享。这个过程旨在逐步从集合中移除运营不佳的验证者，减少他们的委托者的奖励。 188 | 189 | 如果指标保持在更高的阈值以上，验证者将从轮换中移除，并从他们的自委托BNB中扣除一定数量的BNB。这个行为导致验证者和委托者都无法获得他们的质押奖励。 190 | 191 | ## 展望 192 | 我们很难对BNB Chain下定论，因为它从未停止发展。以下是我们目前最关注的主题，这些特性的发展会为社区提供更好的可用性和可扩展性： 193 | 194 | - **并行EVM**。并行EVM是EVM的一个扩展，允许它并行执行多个指令，从而提高网络的性能。 195 | - **状态过期**。通过移除过期的存储状态，解决BNB智能链上不断增加的世界状态存储问题。 196 | - **持续进一步去中心化**。 197 | - **大规模采用基础设施**。BNB Chain社区致力于确保公共基础设施是一流的，并为大规模应用提供基础构建块。 -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # BNB Smart Chain White Paper 2 | 3 | ## Revision 4 | 5 | * Version 0.1, 2020/04/17, initial publish. 6 | * Version 0.1, 2020/05/25, add Chinese version translated by community members. 7 | * Version 0.1, 2020/11/10, add Filipino version translated by @ricoz 8 | * Version 0.2, 2024/8/7, revise the whitepaper after BC fusion -------------------------------------------------------------------------------- /WHITEPAPER.md: -------------------------------------------------------------------------------- 1 | # BNB Smart Chain 2 | 3 | ## Table of Contents 4 | 5 | - [BNB Smart Chain](#bnb-smart-chain) 6 | - [Motivation](#motivation) 7 | - [Evolution of BNB Chain](#evolution-of-bnb-chain) 8 | - [Design Principles](#design-principles) 9 | - [Token Economy](#token-economy) 10 | - [Native Token](#native-token) 11 | - [Seed Fund](#seed-fund) 12 | - [Real-Time Burning](#real-time-burning) 13 | - [Consensus and Validator Quorum](#consensus-and-validator-quorum) 14 | - [Proof of Staked Authority](#proof-of-staked-authority) 15 | - [Validator Set](#validator-set) 16 | - [Validator Election](#validator-election) 17 | - [System Contracts](#system-contracts) 18 | - [Reward Distribution](#reward-distribution) 19 | - [Security and Finality](#security-and-finality) 20 | - [Governance](#governance) 21 | - [Slashing and Penalties](#slashing-and-penalties) 22 | - [Double Sign](#double-sign) 23 | - [Malicious Fast Finality Vote](#malicious-fast-finality-vote) 24 | - [Unavailability](#unavailability) 25 | - [Outlook](#outlook) 26 | 27 | ## Motivation 28 | 29 | 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. 30 | 31 | 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. 32 | 33 | ## Evolution of BNB Chain 34 | 35 | - **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. 36 | 37 | - **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. 38 | 39 | - **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. 40 | 41 | - **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. 42 | 43 | - **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. 44 | 45 | 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. 46 | 47 | 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. 48 | 49 | ## Design Principles 50 | 51 | Here are the design principles of BSC: 52 | 53 | 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. 54 | 55 | 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. 56 | 57 | 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. 58 | 59 | 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. 60 | 61 | ## Token Economy 62 | 63 | BSC, opBNB, and Greenfield share the same token universe for BNB. This defines: 64 | 65 | 1. BNB can circulate on all networks and flow via a cross-chain communication mechanism. 66 | 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. 67 | 68 | ### Native Token 69 | 70 | 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: 71 | 72 | 1. Pay "fees" to deploy smart contracts on BSC. 73 | 2. Stake on selected BSC validators and get corresponding rewards. 74 | 3. Perform cross-chain operations, such as transferring token assets across BSC, opBNB, and Greenfield. 75 | 76 | ### Seed Fund 77 | 78 | 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. 79 | 80 | ### Real-Time Burning 81 | 82 | 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. 83 | 84 | ## Consensus and Validator Quorum 85 | 86 | Based on the above design principles, the consensus protocol of BSC is to fulfill the following goals: 87 | 88 | 1. Blocking time should be shorter than the Ethereum network, e.g., 3 seconds. 89 | 2. It requires limited time to confirm the finality of transactions, e.g., around 10-seconds level or shorter. 90 | 3. There is no inflation of native token: BNB, the block reward is collected from transaction fees, and it will be paid in BNB. 91 | 4. It is compatible with the Ethereum system as much as possible. 92 | 5. It allows modern proof-of-stake blockchain network governance. 93 | 94 | ### Proof of Staked Authority 95 | 96 | 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. 97 | 98 | 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. 99 | 100 | 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. 101 | 102 | BSC here proposes to combine DPoS and PoA for consensus, so that: 103 | 104 | 1. Blocks are produced by a limited set of validators. 105 | 2. Validators take turns to produce blocks in a PoA manner, similar to Ethereum's Clique consensus design. 106 | 3. Validator set are elected in and out based on a staking-based governance. 107 | 4. To enhance network capacity, validators are permitted to produce consecutive blocks within specified parameters. 108 | 109 | ### Validator Set 110 | 111 | 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. 112 | 113 | 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. 114 | 115 | 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. 116 | 117 | ### Validator Election 118 | 119 | There are different roles for validators: 120 | 121 | - **Cabinet:** the top K (which will be 21) validators who get the most chance of producing blocks. 122 | - **Candidate:** the top (K, K+NumOfCandidates]) validators who get a small chance of producing blocks. 123 | - **Inactive:** the rest validators who get no chance of producing blocks. 124 | 125 | ![image](./assets/validator-select.png) 126 | 127 | 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. 128 | 129 | ### System Contracts 130 | 131 | There are several built-in contracts (i.e., system contracts) to facilitate the BSC staking and validator election. 132 | 133 | - **Validator Set Contract:** The contract periodically elects a validator set. The contract also serves as a vault for temporarily storing validator rewards. 134 | 135 | - **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. 136 | 137 | - **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. 138 | 139 | - **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. 140 | 141 | ### Reward Distribution 142 | 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. 143 | 144 | 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. 145 | 146 | ## Security and Finality 147 | 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. 148 | 149 | 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: 150 | 151 | 1. A block is proposed by a validator and propagated to other validators. 152 | 2. Validators use their BLS private key to sign for the block as a vote message. 153 | 3. Gather the votes from validators into a pool. 154 | 4. Aggregate the BLS signature if its direct parent block has gotten enough votes when 155 | proposing a new block. 156 | 5. Set the aggregated vote attestation into the extra field of the new block's header. 157 | 6. Validators and full nodes who received the new block with the direct parent block's 158 | attestation can justify the direct parent block. 159 | 7. If two continuous blocks have been justified, then the previous one is finalized. 160 | 161 | ## Governance 162 | BSC introduces the native governance module, drawing inspiration from the OpenZeppelin Governor. Here are the key features of BSC Governance: 163 | 164 | - **Proposal and Voting Rights**: Staking credit holders can propose and vote on governance matters. 165 | - **Continuous Rewards**: Voters can keep earning staking rewards during the voting period. 166 | - **Flexible Delegation**: Users can delegate their voting rights, enabling others to participate in governance. 167 | - **Secure Execution**: Proposals undergo a time lock period before execution once passed. 168 | 169 | 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. 170 | 171 | ## Slashing and Penalties 172 | 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. 173 | 174 | ### Double Sign 175 | 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. 176 | 177 | 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. 178 | 179 | 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. 180 | 181 | ### Malicious Fast Finality Vote 182 | 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. 183 | 184 | 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. 185 | 186 | ### Unavailability 187 | 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. 188 | 189 | 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. 190 | 191 | 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. 192 | 193 | ## Outlook 194 | 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: 195 | 196 | - **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. 197 | - **State Expiry**. Address the problem of increasing world state storage on the BNB Smart Chain, by removing expired storage state. 198 | - **Non-stop Further Decentralization**. 199 | - **Mass Adoption Infra**. The BNB Chain community is committed to making sure 200 | public infrastructure is top-notch and provides foundational building blocks for large scale applications. 201 | -------------------------------------------------------------------------------- /assets/cross-chain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/whitepaper/5296cec65cee992bb7de46bb18a77ac9f346cef3/assets/cross-chain.png -------------------------------------------------------------------------------- /assets/validator-select.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/whitepaper/5296cec65cee992bb7de46bb18a77ac9f346cef3/assets/validator-select.png -------------------------------------------------------------------------------- /translations/PUTINGPAPEL.md: -------------------------------------------------------------------------------- 1 | # BNB Smart Chain 2 | 3 | **Isang Kahanay na BNB Beacon Chain para Mapatakbo ang mga Matalinong Kontrata** 4 | 5 | _PAALALA: Ang dokumentong ito ay kasalukuyang ginagawa. Mangyaring dumalaw ng madalas para sa mga pagbabago!_ 6 | 7 | ## Talaan ng mga Nilalaman 8 | 9 | - [Pagganyak](#pagganyak) 10 | - [Mga Prinsipyo ng Disenyo](#mga-prinsipyo-ng-disenyo) 11 | - [Pagkakasundo at Korum ng mga Tagapagpatunay](#pagkakasunduan-at-korum-ng-mga-tagapagpatunay) 12 | * [Patunay ng Itinayang Awtoridad](#patunay-ng-itinayang-awtoridad) 13 | * [Korum ng Tagapagpatunay](#korum-ng-tagapagpatunay) 14 | * [Seguridad at Kawakasan](#seguridad-at-kawakasan) 15 | * [Gantimpala](#gantimpala) 16 | - [Ekonomiya ng Token](#ekonomiya-ng-token) 17 | * [Katutubong Token](#katutubong-token) 18 | * [Iba Pang Mga Token](#iba-pang-mga-token) 19 | - [Cross-Chain na Paglipat at Komunikasyon](#cross-chain-na-paglipat-at-komunikasyon) 20 | * [Cross-Chain na Paglipat](#cross-chain-na-paglipat) 21 | * [BC patungo sa BSC na Arkitektura](#bc-patungo-sa-bsc-na-arkitektura) 22 | * [BSC patungo sa BC na Arkitektura](#bsc-patungo-sa-bc-na-arkitektura) 23 | * [Pag-timeout at Pangangasiwa ng Kamalian](#pag-timeout-at-pangangasiwa-ng-kamalian) 24 | * [Cross-Chain na Karanasan ng User](#cross-chain-na-karanasan-ng-user) 25 | * [Kaganapan sa Kontrata ng Cross-Chain](#kaganapan-sa-kontrata-ng-cross-chain) 26 | - [Pagtaya at Pamamahala](#pagtaya-at-pamamahala) 27 | * [Pagtaya sa BC](#pagtaya-sa-bc) 28 | * [Paggantimpala](#paggantimpala) 29 | * [Pagbawas](#pagbawas) 30 | - [Mga Tagahatid](#mga-tagahatid) 31 | * [Mga Tagahatid ng BSC](#mga-tagahatid-ng-bsc) 32 | * [Mga Orakulong Tagahatid](#mga-orakulong-tagahatid) 33 | - [Pananaw](#pananaw) 34 | 35 | # Pagganyak 36 | 37 | Matapos ang [paglunsad](https://www.binance.com/en/blog/327334696200323072/Binance-DEX-Launches-on-Binance-Chain-Invites-Further-Community-Development) sa mainnet noong Abril 2019, ipinamalas ng [BNB Beacon Chain](https://www.bnbchain.org) ang disenyo nitong may mabilis at malaking throughput. Ang [BNB Beacon Chain Dex](https://www.bnbchain.org/trade) na isang katutubong [decentralized application](https://en.wikipedia.org/wiki/Decentralized_application) o “dApp” kung saan nakatuon ang pansin ng BNB Beacon Chain, ay nakapagpakita ng mababang pagkaantala sa pagtutugma at malaking kapasidad sa pamamagitan ng paghawak ng milyun-milyong dami ng kalakalan sa maikling panahon. 38 | 39 | Ang kakayahang umangkop at kakayahang magamit ay kadalasang may kabaligtarang relasyon sa kakayahang pagganap. Ang pagtutok sa pagbibigay ng isang madaling paraan ng pagkakaloob ng mga digital na asset at lugar ng pangangalakal ay nagdudulot din ng mga limitasyon. Ang pinakahinahanap na katangian ng BNB Beacon Chain ay ang programmable extendibility, o sa madaling salita ang [Matalinong Kontrata](https://en.wikipedia.org/wiki/Smart_contract) at Virtual Machine na mga kakayahan. Ang mga tagapagbigay ng mga digital na asset at mga nagmamay-ari nito ay nahihirapan sa pagdagdag ng mga bagong disentralisadong kakayahan para sa kanilang mga assets o magpakilala ng anumang uri ng pamamahala at mga aktibidad sa kanilang komunidad. 40 | 41 | Sa kabila ng mataas na pangangailangan na maglagay ng Matalinong Kontrata na katangian sa BNB Beacon Chain, isa itong mahirap na desisyon. Ang pagtakbo ng isang Matalinong Kontrata ay maaaring makapagpabagal ng kalakalan at magdagdag ng mga hindi matukoy na aspeto sa pangangalakal. Kung kayang tiisin ang kompromiso na maidudulot nito, maaaring maging isang tapat na ideya ang ipakilala ang isang bagong Virtual Machine na may mga katangian na batay sa [Tendermint](https://tendermint.com/core/), batay sa kasalukuyang protokol ng pagkakasunduan at sa pangunahing pagpapatakbo ng RPC ng BNB Beacon Chain. Pero ang lahat ng ito ay magpapataas ng mga kinakailangan sa pag-aaral ng lahat ng mga aktibong mga komunidad ng dApp, at posibleng hindi masyadong malugod na tanggapin. 42 | 43 | Ipinapanukala namin ang isang kahanay na blockchain ng kasalukuyang BNB Beacon Chain para mapanatili ang mataas na kakayahang pagganap ng katutubong DEX blockchain habang suportado ang isang madaling gamitin na Matalinong Kontrata na kakayahan. 44 | 45 | # Mga Prinsipyo ng Disenyo 46 | 47 | Matapos ang paglikha ng kahanay na blockchain sa BNB Beacon Chain ecosystem, dalawang blockchain ang tatakbo ng sabay para magbigay ng iba't ibang mga serbisyo. Ang bagong kahanay na kadena ay tatawaging “**BNB Smart Chain**” (pinaikli na “**BSC**” para sa mga seksyon sa ibaba), habang ang umiiral na mainnet ay tatawagin pa rin na “**BNB Beacon Chain**” (pinaikli na “**BC**” para sa mga seksyon sa ibaba). 48 | 49 | Narito ang mga prinsipyo ng disenyo ng **BSC**: 50 | 51 | 1. **Malayang Blockchain**: Sa panteknikal na salita, ang BSC ay isang nagsasariling blockchain, sa halip na isang layer-2 na solusyon. Karamihan sa mga pangunahing kakayahan ng BSC na panteknikal at pang-negosyo ay dapat na umiiral sa loob ng sarili niya para maaari pa rin itong tumakbo nang maayos kahit na huminto pansamantala ang BC ng maikling panahon. 52 | 2. **Pagkatugma sa Ethereum**: Ang unang praktikal at malawak na ginagamit na platform para sa Matalinong Kontrata ay ang Ethereum. Upang samantalahin ang medyo maunlad na mga aplikasyon at komunidad nito, pinili ng BSC na maging katugma sa umiiral na Ethereum mainnet. Nangangahulugan ito na ang karamihan sa **dApps**, mga bahagi ng ecosystem, at mga iba't ibang kasangkapan ay gagana sa BSC at mangangailangan ng wala o kaunti lang na mga pagbabago; Mangangailangan ang BSC node ng katulad (o medyo mas mataas) na katangian ng hardware at kakayahan para tumakbo at mapatakbo. Ang ganitong pagpapatupad ay dapat mag-iwan ng lugar para sa BSC na makahabol sa karagdagang mga pagsulong ng Ethereum. 53 | 3. **Pagtaya na Kaakibat sa Pagkakasundo at Pamamahala**: Ang pagkakasundo na nakabase sa Pagtaya ay mas mainam sa kapaligiran at nag-iiwan ng mas may kakayahang umangkop na pamamaraan sa pamamahala ng komunidad. Inaasahan na ang ganitong uri ng pakakasundo ay kayang magbigay ng mas mahusay na kakayahang pagganap ng network kaysa [proof-of-work](https://en.wikipedia.org/wiki/Proof_of_work) na sistema ng blockchain, hal. mabilis na oras ng pagbuo ng bloke at mas mataas na kapasidad sa transaksyon. 54 | 4. **Katutubong Cross-Chain na Komunikasyon**: Ang BC at BSC ay parehong papatakbuhin na may sariling suporta para sa cross-chain na komunikasyon sa pagitan ng dalawang mga blockchain. Ang protocol ng komunikasyon nila ay dapat na bi-directional, desentralisado, at di nangangailangan ng tiwala. Tututukan nito ang paglipat ng mga digital na assets sa pagitan ng BC at BSC, ibig sabihin, ang [BEP2](https://github.com/bnb-chain/BEPs/blob/master/BEP2.md) na mga token, at kalaunan, iba pang mga tokens na BEP na ipapakilala sa paglaon. Dapat pangalagaan ng protocol ang minimum ng iba pang mga bagay na nakalagay sa estado ng mga blockchain, na may ilang mga pagbubukod lang. 55 | 56 | # Pagkakasunduan at Korum ng mga Tagapagpatunay 57 | 58 | Batay sa mga prinsipyo ng disenyo sa itaas, ang protokol ng pagkakasunduan ng BSC ay magpapatupad ng mga sumusunod na layunin: 59 | 60 | 1. Ang oras ng pag gawa ng bloke ay dapat na mas maikli kaysa sa Ethereum network, hal. 5 segundo lang o mas maikli pa. 61 | 2. Nangangailangan ito ng limitadong oras para kumpirmahin ang kawakasan ng mga transaksyon, hal. hanggang sa isang minuto o mas maikli pa. 62 | 3. Walang implasyon ng katutubong token: BNB, ang gantimpala ng bloke ay nakolekta mula sa mga bayarin sa transaksyon, at babayaran ito gamit ang BNB. 63 | 4. Ito ay nagkakasundo sa sistema ng Ethereum hangga't maaari. 64 | 5. Pinapayagan nito ang modernong [patunay-ng-taya](https://en.wikipedia.org/wiki/Proof_of_stake) na pamamahala sa blockchain network. 65 | 66 | ## Patunay ng Itinayang Awtoridad 67 | 68 | Bagaman ang Proof-of-Work (PoW) ay kinilala bilang isang praktikal na mekanismo para magpatupad ng isang desentralisadong network, hindi ito mainam sa kapaligiran at nangangailangan din ng isang mataas na bilang ng mga kalahok para mapanatili ang seguridad. 69 | 70 | Ang Ethereum at iba pang mga blockchain network, tulad ng [MATIC Bor](https://github.com/maticnetwork/bor), [TOMOChain](https://tomochain.com/), [GoChain](https://gochain.io/), [xDAI](https://xdai.io/), ay gumagamit ng [Patunay-ng-Awtoridad (PoA)](https://en.wikipedia.org/wiki/Proof_of_authority) o ang mga uri nito sa iba't ibang mga sitwasyon, kabilang ang parehong testnet at mainnet. Nagbibigay ang PoA ng ilang depensa sa 51% na atake, na may pinahusay na liksi at pagpapaubaya sa ilang mga antas ng mga manlalaro ng Byzantine (may masamang hangarin o na-hack). Nagsisilbi itong isang madaling pagpipilian na hirangin bilang mga pangunahing kakayahan. 71 | 72 | Samantala, ang PoA na protokol ay pinupuna dahil sa pagiging hindi kasing desentralisado ng PoW, dahil ang mga tagapagpatunay, o ang mga node na nagpapalit-palitan sa pagbuo ng mga bloke, ay mayroong lahat ng awtoridad kaya madaling matukso sa katiwalian at maatake ang seguridad. Ang iba pang mga blockchain, tulad ng EOS at Lisk, ay parehong nagpapakilala ng iba't ibang uri ng [Delegated Proof of Stake (DPoS)](https://en.bitcoinwiki.org/wiki/DPoS) para payagan ang mga may hawak ng token na bumoto at piliin ang grupo ng mga tagapagpatunay. Nadadagdagan nito ang desentralisasyon at mas pinapaboran ang pamamahala ng komunidad. 73 | 74 | Iminumungkahi ng BSC na pagsamahin ang DPoS at PoA para sa pagkakasunduan, para: 75 | 1. Ang mga bloke ay ginawa ng isang limitadong grupo ng mga tagapagpatunay 76 | 2. Nagpapalit-palitan ang mga tagapagpatunay para makabuo ng mga bloke sa pamamaraan ng PoA, katulad sa disenyo ng pagkakasunduan ng [Ethereum's Clique](https://eips.ethereum.org/EIPS/eip-225) 77 | 3. Ang hanay ng tagapagpatunay ay inihalal sa loob at labas batay sa isang pamamahalang nakabatay sa pagtaya 78 | 79 | ## Korum ng Tagapagpatunay 80 | 81 | Sa yugto ng genesis, ang ilang mga pinagkakatiwalaang node ay tatakbo bilang paunang Hanay ng Tagapagpatunay. Matapos magsimula ang pag gawa ng bloke, ang sinuman ay maaaring makipagkumpitensya para sumali bilang mga kandidato sa pagiging isang tagapagpatunay. Ang istado ng pagtaya ay magpapasiya sa nangungunang 21 pinaka tinayaang node na maging susunod na hanay ng tagapagpatunay, at ang gayong halalan ay uulitin bawat 24 na oras. 82 | 83 | Ang **BNB** ay ang token na ginagamit para maitaya para sa BSC. 84 | 85 | Upang manatiling katugma ng Ethereum at maisulong sa mga gagawin pa lang na mga protokol ng pagkakasunduan sa hinaharap, pipiliin ng BSC na umasa sa **BC** para sa pangangasiwa ng pagtaya (Mangyaring sumangguni sa “[Pagtaya at Pamamahala](#pagtaya-at-pamamahala)” na seksyon sa ibaba). Mayroong **dedikadong modyul ng pagtaya para sa BSC sa BC**. Tatanggapin nito ang pagtaya sa BSC mula sa mga may hawak ng BNB at kakalkulahin ang pinakamataas na tinayaang hanay ng node. Sa tuwing hatinggabi ng UTC, maglalabas ang BC ng isang mapapatunayan na `ValidatorSetUpdate` na mensaheng cross-chain para abisuhan ang BSC na palitan ng pinakabago ang hanay ng tagapagpatunay nito. 86 | 87 | Habang gumagawa ng karagdagang mga bloke, susuriin ng umiiral na mga tagapagpatunay ng BSC kung mayroong isang mensahe na `ValidatorSetUpdate` na naipadala sa BSC pana-panahon. Kung meron, babaguhin nila ang hanay ng tagapagpatunay pagkatapos ng isang **epoch na panahon**, ibig sabihin, isang paunang natukoy na bilang ng oras ng pag gawa ng bloke. Halimbawa, kung ang BSC ay gumagawa ng isang bloke tuwing 5 segundo, at ang epoch na panahon ay 240 bloke, ang kasalukuyang hanay ng tagapagpatunay ay susuriin at babaguhin ang hanay ng tagapagpatunay para sa susunod na epoch sa 1200 segundo (20 minuto). 88 | 89 | ## Seguridad at Kawakasan 90 | 91 | Dahil mayroong higit sa ½\*N+1 na mga tagapagpatunay na matapat, ang mga network na nakabatay sa PoA ay karaniwang gumagana nang ligtas at maayos. Gayunpaman, may mga kaso pa rin kung saan ilang tagapagpatunay ng Byzantine ay maaari pa ring magawang atakein ang network, hal. sa pamamagitan ng “[Clone na Atake](https://arxiv.org/pdf/1902.10244.pdf)”. Upang maging kasing ligtas ng BC, hinihimok ang mga user ng BSC na maghintay hanggang sa makatanggap ng mga bloke na tinatakan ng higit sa ⅔\*N+1 magkakaibang mga tagapagpatunay. Sa ganoong paraan, ang BSC ay mapagkakatiwalaan sa katulad na antas ng seguridad sa BC at maaaring tiisin ang mas mababa sa ⅓\*N na mga tagapagpatunay ng Byzantine. 92 | 93 | Sa 21 mga tagapagpatunay, kung ang oras ng bloke ay 5 segundo, ang ⅔\*N+1 na magkakaibang mga tatak ng tagapagpatunay ay mangangailangan ng haba ng oras na (⅔\*21+1)*5 = 75 segundo. Anumang mga kritikal na aplikasyon para sa BSC ay maaaring maghintay ng ⅔\*N+1 para matiyak ang isang ligtas na kawakasan. Gayunpaman, bukod sa naturang pagkakaayos, ang BSC ay nagpapakilala ng **Pagbawas** na lohika para maparusahan ang mga tagapagpatunay ng Byzantine para sa **dobleng pagpirma** o **hindi nagagamit**, na tatalakayin sa seksyong “Pagtaya at Pamamahala” mamaya. Ang Pagbawas na lohika na ito ay ilalantad ang mga may masamang hangarin na tagapagpatunay sa isang napakaikling panahon at gagawin ang “Clone na Atake” na napakahirap o labis na hindi kapaki-pakinabang para maipatupad. Sa pagpapahusay na ito, ang ½\*N+1 o kahit na mas kaunting mga bloke ay sapat na bilang kumpirmasyon para sa karamihan ng mga transaksyon. 94 | 95 | ## Gantimpala 96 | 97 | Lahat ng mga tagapagpatunay ng BSC sa kasalukuyang hanay ng tagapagpatunay ay gagantimpalaan ng mga **bayarin sa transaksyon gamit ang BNB**. Dahil ang BNB ay hindi isang inflationary token, hindi magkakaroon ng mga gantimpala sa pagmimina gaya ng binibigay ng Bitcoin at Ethereum network, at ang bayarin sa gas ay ang pangunahing gantimpala para sa mga tagapagpatunay. Dahil ang BNB ay mga utility token din na may iba pang mga gamit, tatangkilikin pa rin ng mga delegado at tagapagpatunay ang iba pang mga benepisyo ng paghawak ng BNB. 98 | 99 | Ang gantimpala para sa mga tagapagpatunay ay ang mga bayarin na nakolekta mula sa mga transaksyon sa bawat bloke. Maaaring magpasya ang mga tagapagpatunay kung magkano ang ibabalik sa mga delegado na tumaya sa kanila ng kanilang BNB, para makaakit ng mas madaming taya. Ang bawat tagapagpatunay ay magpapalitan para makabuo ng mga bloke sa parehong posibilidad (kung mananatili sila sa 100% na pagka aktibo), sa gayon, sa pangmatagalan, ang lahat ng mga matatag na tagapagpatunay ay maaaring makakuha ng magkakatulad na laki ng gantimpala. Samantala, ang mga taya sa bawat tagapagpatunay ay maaaring magkakaiba, kaya nagdadala ito ng isang kontra-intuitive na sitwasyon na mas madaming mga user ang nagtitiwala at naglalaan sa isang tagapagpatunay, maaaring makakuha sila ng mas kaunting gantimpala. Kaya't ang mga makatuwiran na delegado ay may posibilidad na magtalaga sa isa na may mas kaunting taya hangga't ang tagapagpatunay ay mapagkakatiwalaan pa rin (ang walang katiyakan na tagapagpatunay ay maaaring magdala ng peligro na pagbawas). Sa huli, ang mga taya sa lahat ng mga tagapagpatunay ay magkakaroon ng mas kaunting pagkakaiba-iba. Ito ay talagang pipigilan ang konsentrasyon ng taya at ang “nanalo ay mananalo palagi” na problemang nakikita sa ilang iba pang mga network. 100 | 101 | Ang ilang mga bahagi ng bayarin sa gas ay igagantimpala din sa mga tagahatid para sa Cross-Chain na komunikasyon. Mangyaring mag-refer sa seksyong “[Tagahatid](#tagahatid)” sa ibaba. 102 | 103 | # Ekonomiya ng Token 104 | 105 | Ang BC at BSC ay naghahati sa parehong sandaigdig ng token para sa mga tokens na BNB at BEP2. Tinutukoy nito: 106 | 107 | 1. Ang parehong token ay maaaring umikot sa dalawang network, at dumadaloy sa pagitan ng mga ito ng magkabilaang direksyon sa pamamagitan ng mekanismo ng cross-chain na komunikasyon. 108 | 2. Ang kabuuang sirkulasyon ng parehong token ay dapat na pangasiwaan sa dalawang network, ibig sabihin, ang kabuuang epektibo na suplay ng isang token ay dapat na suma ng kabuuang epektibo na supply ng token sa parehong BSC at BC. 109 | 3. Ang mga tokens ay maaaring unang likhain sa BSC sa isang katulad na ayos sa ERC20 token na pamantayan, o sa BC bilang isang BEP2, pagkatapos ay nilikha sa kabila. Mayroong mga katutubong paraan sa parehong mga network para maidugtong ang dalawa at i-sigurado ang kabuuang supply ng token. 110 | 111 | ## Katutubong Token 112 | 113 | Ang BNB ay tatakbo sa BSC sa parehong paraan tulad ng ETH na tumatakbo sa Ethereum para manatili ito bilang "katutubong token" para sa parehong BSC at BC. Nangangahulugan ito, bilang karagdagan sa BNB na ginagamit para bayaran ang karamihan sa mga bayarin sa BNB Beacon Chain at BNB DEX, gagamitin din ang BNB para: 114 | 115 | 1. magbayad ng "bayarin" para makapag lunsad ng mga matalinong kontrata sa BSC 116 | 2. itaya sa mga piling tagapagpatunay ng BSC, at makakuha ng kaukulang gantimpala 117 | 3. magsagawa ng mga operasyon na cross-chain, tulad ng paglipat ng mga token asset sa kabuuan ng BC at BSC 118 | 119 | ### Pondong Binhi 120 | 121 | Ang ilang mga halaga ng BNB ay susunugin sa BC at huhulmahin sa BSC sa yugto ng genesis. Ang halagang ito ay tinatawag na "Pondong Binhi" para mag-ikot sa BSC pagkatapos ng unang bloke, na ipapadala sa paunang BC-patungo-sa-BSC na Tagahatid (inilarawan sa mga susunod na seksyon) at paunang itinakdang hanay ng tagapagpatunay na ipinakilala sa genesis. Ang mga BNB na ito ay ginagamit para magbayad ng mga bayarin sa transaksyon habang maaga para ilipat ang mas madaming BNB mula sa BC patungo sa BSC sa pamamagitan ng mekanismo ng cross-chain. 122 | 123 | Ang BNB cross-chain na paglipat ay tinalakay sa isang susunod na seksyon, pero para sa paglipat mula sa BC patungong BSC, sa pangkalahatan ito ay para i-lock ang BNB sa BC mula sa pinagmulang address ng paglipat sa isang address na kontrolado ng sistema at i-unlock ang kaukulang halaga mula sa espesyal na kontrata papunta sa target na address ng paglipat sa BSC, o sa kabaligtaran, kapag ililipat mula sa BSC patungong BC, ito ay para i-lock ang BNB mula sa pinagmulang address sa BSC patungo sa isang espesyal na kontrata at palabasin ang naka-lock na halaga sa BC mula sa address ng sistema patungo sa target na address. Ang lohika ay nauugnay sa katutubong kodigo sa BC at isang serye ng mga matalinong kontrata sa BSC. 124 | 125 | ## Iba Pang Mga Token 126 | 127 | Sinusuportahan ng BC ang mga tokens na BEP2 at paparating na [mga tokens na BEP8](https://github.com/bnb-chain/BEPs/pull/69), na mga katutubong asset na maililipat at maibebenta (kung nakalista) sa pamamagitan ng mabilis na mga transaksyon at mababa sa isang segundong kawakasan. Samantala, dahil ang BSC ay katugma sa Ethereum, natural na suportahan ang mga tokens na ERC20 sa BSC, na kung saan dito ay tinatawag na “**BEP2E**” (na ang tunay na pangalan ay ipapakilala ng mga BEP sa hinaharap, potensyal itong sumasakop din sa BEP8). Ang BEP2E ay maaaring "Pinahusay" sa pamamagitan ng pagdaragdag ng ilang mga kakayahan para mailantad ang higit pang impormasyon, tulad ng denominasyon ng token, kahulugan ng katumpakan ng desimal at ang address ng may-ari na maaaring magpasya sa Token Binding sa mga kadena. Ang BSC at BC ay nagtutulungan para matiyak na ang isang token ay maaaring umikot sa parehong ayos na may kumpirmadong kabuuang panustos at magagamit sa iba't ibang mga kaso ng paggamit. 128 | 129 | ### Pagbigkis ng Token 130 | 131 | Ang mga tokens na BEP2 ay ipapalawak para magsama ng isang bagong katangian para maiugnay ang token sa isang kontrata ng token ng BSC BEP2E, na tinatawag na “**Tagabigkis**”, at ang prosesong ito ng pagugnay ay tinatawag na “**Pagbigkis ng Token**”. 132 | 133 | Ang Pagbigkis ng Token ay maaaring mangyari sa anumang oras matapos maging handa na ang BEP2 at BEP2E. Ang mga may-ari ng token na alinman sa BEP2 o BEP2E ay hindi kailangang mag-abala tungkol sa Pagbigkis, hanggang sa bago nila talagang nais na gamitin ang mga tokens sa iba't ibang mga sitwasyon. Ang mga tagapagbigay ay maaaring lumikha ng BEP2 muna o BEP2E muna, at maaari silang maibigkis sa ibang pagkakataon. Siyempre, hinihikayat para sa lahat ng mga tagapagbigay ng BEP2 at BEP2E na itakda nang maaga ang Pagbigkis pagkatapos ng pagbigay. 134 | 135 | Ang isang tipikal na pamamaraan para maibigkis ang BEP2 at BEP2E ay magiging katulad sa ibaba: 136 | 137 | 1. Tiyaking kapwa ang token na BEP2 at ang token na BEP2E ay parehong umiiral sa bawat blockchain, na may parehong kabuuang supply. Ang BEP2E ay dapat mayroong 3 higit pang mga pamamaraan kaysa sa karaniwang ERC20 token na pamantayan: 138 | * `symbol()`: kunin ang simbolo ng token 139 | * `decimals()`: kunin ang bilang ng mga desimal na numero ng token 140 | * `owner()`: kunin ang **address ng may-ari ng kontrata ng BEP2E.** Ang halagang ito ay dapat na ipasimula sa taga-buo ng kontrata ng BEP2E para ang karagdagang pagbigkis na pagkilos ay maaaring magpatunay kung ang aksyon ay mula sa may-ari ng BEP2E. 141 | 142 | 2. Pagpasyahan ang paunang sirkulasyon sa parehong mga blockchain. Ipagpalagay na ang kabuuang supply ay *S*, at ang inaasahang paunang iikot na supply sa BC ay *K*, kung gayon dapat mag-lock ang may-ari ng S-K na dami ng token sa isang address na kontrolado ng sistema sa BC. 143 | 144 | 3. Katumbas nito, may *K* na dami ng mga tokens na naka-lock sa espesyal na kontrata sa BSC, na humahawak ng mga pangunahing kakayahan na pagbigkis at pinangalanang **TokenHub**. Ang tagapagbigay ng token na BEP2E ay dapat i-lock ang may *K* na dami ng mga tokens na iyon sa TokenHub, na magreresulta sa *S-K* na dami ng mga tokens na iikot sa BSC. Sa gayon ang kabuuang sirkulasyon sa 2 blockchain ay mananatili bilang *S*. 145 | 146 | 4. Ang nagbigay ng token na BEP2 ay nagpapadala ng transaksyon na pagbigkis sa BC. Kapag ang transaksyon ay matagumpay na naisakatuparan pagkatapos ng wastong pagpapatunay: 147 | * Naglilipat ito ng mga tokens na may *S-K* na dami sa isang address na kontrolado ng sistema sa BC. 148 | * Malilikha ang isang pakete na may hiling na cross-chain na pagbigkis, naghihintay para sa mga tagahatid na maghatid. 149 | 150 | 5. Ang mga Tagahatid sa BSC ay maghahatid ng pakete na may hiling na cross-chain na pagbigkis papunta sa **TokenHub** sa BSC, at ang kaukulang kahilingan at impormasyon ay ilalagay sa kontrata. 151 | 152 | 6. Ang may-ari ng kontrata at ang may-ari lang ang maaaring magpatakbo ng isang espesyal na pamamaraan ng kontrata ng TokenHub, ang `ApproveBind`, para mapatunayan ang hiling na pagbigkis para markahan ito bilang isang tagumpay. Kukumpirmahin nito: 153 | * ang token ay hindi pa nakabigkis; 154 | * ang pagbigkis ay para sa tamang simbolo, na may wastong kabuuang suplay at impormasyong desimal; 155 | * ang tamang lock ay tapos na sa parehong mga network; 156 | 157 | 10. Kapag nagtagumpay ang pamamaraang `ApproveBind`, mamarkahan ng TokenHub ang dalawang mga tokens na nakabigkis na at magkabahagi sa parehong sirkulasyon sa BSC, at ang istado ay ikakalat pabalik sa BC. Matapos ang pangwakas na kumpirmasyon na ito, ang address ng kontrata ng BEP2E at mga desimal ay isusulat sa token na BEP2 bilang isang bagong katangian sa BC, at ang mga tokens ay maaaring mailipat sa dalawang mga blockchain na magkabilaang direksyon. Kung nabigo ang ApproveBind, ang kaganapan ng kabiguan ay ikakalat din pabalik sa BC para palabasin ang mga naka-lock na token, at ang mga hakbang sa itaas ay maaaring subukang ulit sa paglaon. 158 | 159 | # Cross-Chain na Paglipat at Komunikasyon 160 | 161 | Ang cross-chain na komunikasyon ay ang pangunahing pundasyon para payagan ang komunidad na samantalahin ang istraktura ng dalawahang kadena: 162 | 163 | * Ang mga user ay malayang lumikha ng anumang tokenization, mga produktong pampinansyal, at mga digital na assets sa BSC o BC ayon sa gusto nila 164 | * ang mga item sa BSC ay maaaring manu-manong at naka-program na ikakalakal at ikakalat sa isang matatag, mataas na throughput, kasingbilis ng kidlat at magiliw na kapaligiran ng BC 165 | * Maaaring mapatakbo ng mga user ang mga ito sa isang UI at ecosystem ng mga kasangkapan. 166 | 167 | ## Cross-Chain na Paglipat 168 | 169 | Ang cross-chain na paglipat ay ang pangunahing komunikasyon sa pagitan ng dalawang mga blockchain. Sa madaling sabi ang lohika ay: 170 | 171 | 1. ang `transfer-out` blockchain ay ikakandado ang halaga mula sa mga address ng may-ari ng pinagmulan sa isang kinokontrol ng sistema na address/mga kontrata; 172 | 2. ang `transfer-in` blockchain ay bubuksan ang halaga mula sa kinokontrol ng sistema na address/ mga kontrata at ipadala ito sa mga target na address. 173 | 174 | Dapat pahintulutan ng mensahe ng cross-chain na pakete ng paglipat ang BSC na mga Tagahatid at BC na mga **Orakulong Tagahatid** na patunayan: 175 | 176 | 1. Sapat na halaga ng mga token assets ay inalis mula sa pinagmulang address at naka-lock sa isang kontrolado ng sistema na mga address/mga kontrata sa pinagmulang blockchain. At maaaring makumpirma ito sa target na blockchain. 177 | 2. Ang mga wastong halaga ng mga token assets ay inilabas mula sa kontrolado ng sistema na mga address/mga kontrata at inilalaan sa mga target na address sa target na blockchain. Kung nabigo ito, makukumpirma ito sa pinagmulang blockchain, para ang naka-lock na token ay maaaring mailabas pabalik (maaaring ibawas ang mga bayarin). 178 | 3. Ang suma ng kabuuang sirkulasyon ng mga token assets sa kabuuan ng 2 mga blockchain ay hindi binago matapos makumpleto ang paglipat na kilos, kung magtagumpay man ang paglipat o hindi. 179 | 180 | ![cross-chain](./assets/cross-chain.png) 181 | 182 | Ang arkitektura ng cross-chain na komunikasyon ay tulad ng nasa itaas na diagram. Upang mapaunlakan ang 2 mga heteroid na sistema, ang paghawak ng komunikasyon ay magkakaiba sa bawat direksyon. 183 | 184 | ## BC patungo sa BSC na Arkitektura 185 | 186 | Ang BC ay isang blockchain na nakabatay sa Tendermint at may kagyat na kawakasan. Ang mga Tagapagpatunay na may hindi bababa sa ⅔\*N+1 ng kabuuang kapangyarihan sa pagboto ay kasabay na mag pipirma ng bawat bloke sa kadena. Kaya't praktikal na patunayan ang mga transaksyon sa bloke at kahit ang halaga ng estado sa pamamagitan ng **Ulo ng Bloke** at **Patunay na Merkle** nag pagpapatunay. Nasaliksik ito at ipinatupad bilang “**Protokol na Magaan na Kliyente**”, na masidhing tinalakay sa komunidad ng [Ethereum](https://github.com/ethereum/wiki/wiki/Light-client-protocol), pinag-aralan at ipinatupad para sa [Cosmos inter-chain na komunikasyon](https://github.com/cosmos/ics/blob/a4173c91560567bdb7cc9abee8e61256fc3725e9/spec/ics-007-tendermint-client/README.md). 187 | 188 | Ang komunikasyon na BC-patungo-sa-BSC ay papatunayan sa isang “**on-chain na magaan na kliyente**” na ipinatupad sa pamamagitan ng BSC na **Mga Matalinong Kontrata** (ang ilan sa mga ito ay maaaring “**pre-compiled**”). Matapos ang ilang mga transaksyon at pagbabago ng estado na nangyari sa BC, kung ang isang transaksyon ay itinakda na mag-udyok ng cross-chain na komunikasyon, ang mensahe ng “**pakete**” na Cross-chain ay malilikha at ang **BSC na mga Tagahatid** ay magpapasa at magsusumite ng mga ito sa BSC bilang datos sa "build-in na mga sistemang kontrata". Ang mga build-in na mga sistemang kontrata ay papatunayan ang pakete at isasagawa ang mga transaksyon kung pumasa ito sa pagpapatunay. Gagarantiyahan ang pagpapatunay ng disenyo sa ibaba: 189 | 190 | 1. Ang estado sa pag-bloke ng BC ay isisink sa mga magaan na kliyente na kontrata sa BSC paminsan-minsan, sa pamamagitan ng ulo ng bloke at paunang mga komit, para sa mga impormasyon sa ibaba: 191 | * bloke at app hash ng BC na napirmahan ng mga tagapagpatunay 192 | * kasalukuyang hanay ng mga tagapagpatunay, at pinakabagong hanay ng mga tagapagpatunay 193 | 194 | 2. ang susi-halaga mula sa estado ng blockchain ay papatunayan batay sa Patunay na Merkle at impormasyon mula sa itaas #1. 195 | 196 | Matapos kumpirmahing na ang susi-halaga ay tumpak at mapagkakatiwalaan, ang build-in na mga sistemang kontrata ay isasagawa ang mga aksyon na naaayon sa mga cross-chain na pakete. Ang ilang mga halimbawa ng naturang mga pakete na maaaring likhain para sa BC-patungo-sa-BSC ay: 197 | 198 | 1. Bind: ibigkis ang mga tokens ng BEP2 at BEP2E 199 | 2. Paglipat: paglipat ng mga tokens pagkatapos ng pagbigkis, nangangahulugan ito na ang sirkulasyon ay bababa (mai-lock) mula sa BC at lilitaw sa balanse ng target na address sa BSC 200 | 3. Pangangasiwa ng Kamalian: para hawakan ang anumang kaganapan sa pag-timeout/pagkabigo para sa komunikasyon ng BSC-patungo-sa-BC 201 | 4. Pinakabagong hanay ng mga tagapagpatunay ng BSC 202 | 203 | Upang matiyak na walang pagkopya, tamang pagkakasunud-sunod ng mensahe at napapanahong pag-timeout, mayroong isang konseptong "Channel" na ipinakilala sa BC para pangasiwaan ang anumang uri ng komunikasyon. 204 | 205 | Para sa mga tagahatid, mangyaring mag-refer din sa ibaba ng seksyong "Tagahatid". 206 | 207 | ## BSC patungo sa BC na Arkitektura 208 | 209 | Gumagamit ang BSC ng Patunay ng Itinayang Awtoridad na protokol ng pagkakasunduan, na mayroong pagkakataon na magsanga at nangangailangan ng kumpirmasyon ng mas madaming mga bloke. Ang isang bloke ay mayroon lang pirma ng isang tagapagpatunay, kaya't hindi madaling umasa sa isang bloke para mapatunayan ang datos mula sa BSC. 210 | 211 | Upang ganap na samantalahin ang korum ng tagapagpatunay ng BC, isang ideyang katulad sa maraming [Tulay](https://github.com/poanetwork/poa-bridge) o Orakulong mga blockchain ang gagamitin: 212 | 213 | 1. Ang mga kahilingan sa cross-chain na komunikasyon mula sa BSC ay isusumite at isinasagawa sa BSC bilang mga transaksyon. Ang pagsasagawa ng transanction ay magpapalabas ng `Events`, at ang mga naturang kaganapan ay maaaring sundin at ibalot sa ilang mga “**Orakulo**” papunta sa BC. Sa halip na Mga Ulo ng Bloke, Hash at Patunay na Merkle, ang ganitong uri ng "Orakulo" na pakete na direktang naglalaman ng impormasyong cross-chain para sa mga pagkilos, tulad ng nagpadala, tatanggap at halaga na ililipat. 214 | 2. Upang matiyak ang seguridad ng Orakulo, ang mga tagapagpatunay ng BC ay bubuo ng isa pang korum ng mga “**Orakulong Tagahatid**”. Ang bawat tagapagpatunay ng BC ay dapat magpatakbo ng isang **nakatuon na proseso** bilang Orakulong Tagahatid. Ang mga Orakulong Tagahatid na ito ay magsusumite at magboboto para sa cross-chain na pakete ng komunikasyon, tulad ng Orakulo, papunta sa BC, gamit ang parehong mga susi ng tagapagpatunay. Anumang pakete na nilagdaan ng higit sa ⅔\*N+1 na kapangyarihan ng pagboto ng mga Orakulong Tagahatid ay kasing ligtas ng anumang bloke na nilagdaan ng ⅔\*N+1 ng parehong kapangyarihan ng pagboto ng korum ng mga tagapagpatunay. 215 | 216 | Sa paggamit ng parehong korum ng tagapagpatunay, nilalagay nito ang kodigo ng magaan na kliyente sa BC at ang tuluy-tuloy na mga pagbabago ng bloke sa BC. Ang nasabing mga Orakulo ay mayroon ding mga Orakulo ID at uri, para matiyak ang pagkakasunud-sunod at wastong pangangasiwa ng kamalian. 217 | 218 | ## Pag-timeout at Pangangasiwa ng Kamalian 219 | 220 | May mga sitwasyon na hindi nagtatagumpay ang komunikasyon sa cross-chain. Halimbawa, ang hinatid na pakete ay hindi maaaring maipatupad sa BSC dahil sa ilang mga mali sa kodigo ng mga kontrata. **Ang pag-timeout at Pangangasiwa ng Kamalian na mga lohika** ay ginagamit sa mga nasabing senaryo. 221 | 222 | Para sa kilalang mga kamalian ng user at ng sistema o anumang inaasahang pagbubukod, dapat na pagalingin ng dalawang network ang kanilang sarili. Halimbawa, kapag nabigo ang paglipat galing sa BC patungo sa BSC, maglalabas ang BSC ng isang kaganapan sa kabiguan at ang mga Orakulong Tagahatid ay magsasagawa ng isang pagsasauli ng bayad sa BC; kapag nabigo ang paglipat galing sa BSC patungo sa BC, maglalabas ang BC ng isang pakete ng pagsasauli ng bayad para ihatid ng Tagahatid para ma-unlock ang pondo. 223 | 224 | Gayunpaman, ang hindi inaasahang pagkakamali o pagbubukod ay maaari pa ring mangyari sa anumang hakbang ng cross-chain na komunikasyon. Sa ganitong kaso, matutuklasan ng Tagahatid at mga Orakulong Tagahatid na ang kaukulang cross-chain channel ay natigil sa isang partikular na pagkakasunud-sunod. Pagkatapos ng isang yugto ng Pag-timeout, ang mga Tagahatid at mga Orakulong Tagahatid ay maaaring humiling ng isang transaksyon na “SkipSequence”, ang natigil na pagkakasunud-sunod ay mamarkahan bilang "Hindi mapatakbo". Itataas ang isang kaukulang alerto, at kailangang talakayin ng komunidad kung paano pangangasiwaan ang senaryong ito, hal. ibalik ang bayad sa pamamagitan ng isponsor ng mga tagapagpatunay, o kahit na linisin ang pondo sa susunod na pagbago sa network. 225 | 226 | ## Cross-Chain na Karanasan ng User 227 | 228 | Mas mainam na ang mga user ay umaasang gagamit ng dalawang magkatulad na mga kadena sa parehong paraan tulad ng paggamit nila ng isang solong kadena. Nangangailangan ito ng mas madaming pinagsama-samang mga uri ng transaksyon para maidagdag sa cross-chain na komunikasyon para paganahin ito, na magdaragdag ng labis na pagkakumplikado, mahigpit na pagkakaugnay, at pagpapanatili na pasanin. Dito ipinapatupad lang ng BC at BSC ang mga pangunahing operasyon para paganahin ang daloy ng halaga sa paunang paglulunsad at iwanan ang karamihan ng trabaho sa karanasan ng user sa UI na panig ng kliyente, tulad ng mga pitaka. Hal. ang isang mahusay na pitaka ay maaaring payagan ang mga user na magbenta ng isang token nang direkta mula sa BSC papunta sa DEX order book ng BC, sa isang ligtas na paraan. 229 | 230 | ## Kaganapan sa Kontrata ng Cross-Chain 231 | 232 | Ang Kaganapan sa Kontrata ng Cross-Chain (CCCE) ay idinisenyo para payagan ang isang matalinong kontrata na mag-udyok ng mga cross-chain na transaksyon, direkta sa pamamagitan ng kodigo ng kontrata. Nagiging posible ito batay sa: 233 | 234 | 1. Ang karaniwang mga sistemang kontrata ay maaaring ibigay para maghatid ng mga operasyon na maaaring tawagin ng pangkalahatang matalinong mga kontrata; 235 | 2. Ang karaniwang mga kaganapan ay maaaring mailabas ng karaniwang mga kontrata; 236 | 3. Ang mga Orakulong Tagahatid ay maaaring makuha ang karaniwang mga kaganapan, at ma-udyok ang kaukulang mga operasyon ng cross-chain; 237 | 4. Ang nakatuon na address na pinangangasiwaan ng kodigo (account) ay maaaring likhain sa BC at mai-access ng mga kontrata sa BSC, dito pinangalanan bilang **Address ng Kontrata sa BC” (CAoB)**. 238 | 239 | Maraming karaniwang pagpapatakbo ang ipinatupad: 240 | 241 | 1. BSC patungo sa BC na paglipat: ipinatupad ito sa parehong paraan tulad ng normal na BSC patungo sa BC na paglipat, nag-uudyok lang sa pamamagitan ng karaniwang kontrata. Ang pondo ay maaaring ilipat sa anumang address sa BC, kabilang ang kaukulang CAoB ng kontrata na pinagmulan ng paglipat. 242 | 2. Paglipat sa BC: ipinapatupad ito bilang isang espesyal na cross-chain na paglipat, habang ang totoong paglipat ay mula sa **CAoB** papunta sa anumang iba pang address (kahit na isa pang CAoB). 243 | 3. BC patungo sa BSC na paglipat: ipinatutupad ito bilang dalawang-pass na cross-chain na komunikasyon. Ang una ay na-udyok ng kontrata ng BSC at pinalaganap sa BC, at pagkatapos ay sa pangalawang pass, magsisimula ang BC ng isang normal na BC patungo sa BSC cross-chain na paglipat, mula sa **CAoB** hanggang sa address ng kontrata sa BSC. Ang isang espesyal na tala ay dapat bayaran na ang kontrata ng BSC ay nagdaragdag lang ng balanse sa anumang paglipat na papasok sa pangalawang pass, at ang pangangasiwa ng kamalian sa pangalawang pass ay kapareho ng normal na BC patungo sa BSC na paglipat. 244 | 4. IOC (Agaran-O-Kanselahin) na Kalakalan Palabas: ang pangunahing layunin ng paglilipat ng mga assets sa BC ay ang makipagkalakalan. Ang kaganapan na ito ay magtuturo para ipagpalit ang isang tiyak na halaga ng isang asset sa CAoB sa isa pang pag-aari hangga't maaari at ilipat palabas ang lahat ng mga resulta, ibig sabihin, ang natira, ang mapagkukunan at mga ipinalit na target na token ng kalakalan, pabalik sa BSC. Hahawakan ng BC ang mga nasabing hinatid na kaganapan sa pamamagitan ng pagpapadala ng isang "Agaran-O-Kanselahin", ibig sabihin, IOC na utos sa mga pares ng pangangalakal, sa sandaling ang susunod na pagtutugma ay natapos, ang resulta ay maihahatid pabalik sa BSC, na maaaring nasa alinman sa isa o dalawang mga pag-aari. 245 | 5. Subasta na Kalakalan Palabas: Ang naturang kaganapan ay magtuturo sa BC na magpadala ng isang subasta na utos para ipagpalit ang isang tiyak na halaga ng isang asset sa **CAoB** sa isa pang pag-aari hangga't maaari at ilipat palabas ang lahat ng mga resulta pabalik sa BSC sa pagtatapos ng subasta Paparating ang pagpapaandar sa subasta sa BC. 246 | 247 | Mayroong ilang mga detalye para sa Kalakalan Palabas: 248 | 249 | 1. kapwa maaaring magkaroon ng isang limitasyong presyo (ganap o naaayon) para sa kalakal; 250 | 2. ang huling resulta ay isusulat bilang mga cross-chain na pakete para maihatid pabalik sa BSC; 251 | 3. ang mga bayarin sa cross-chain na komunikasyon ay maaaring singilin mula sa asset na inilipat pabalik sa BSC; 252 | 4. ang kontrata ng BSC ay nagpapanatili ng isang salamin ng balanse at natitirang mga order sa CAoB. Hindi alintana kung anumang kamalian ang mangyari sa panahon ng Kalakalan Palabas, ang huling katayuan ay ikakalat pabalik sa pinagmulan na kontrata at linisin ang panloob na estado. 253 | 254 | Sa mga katangian sa itaas, nagdaragdag lang ito ng cross-chain na paglipat at mga kakayahan na maglipat na may mataas na liquidity sa lahat ng mga matalinong kontrata sa BSC. Lalo nitong idaragdag ang mga sitwasyon ng aplikasyon sa Matalinong Kontrata at dApps, at gagawing 1 kadena +1 kadena > 2 kadena. 255 | 256 | # Pagtaya at Pamamahala 257 | 258 | Ang Patunay ng Itinayang Awtoridad ay nagdudulot ng desentralisasyon at paglahok sa komunidad. Ang pangunahing lohika nito ay maaaring ibuod ayon sa ibaba. Maaari kang makakita ng mga katulad na ideya mula sa iba pang mga network, lalo na ang Cosmos at EOS. 259 | 260 | 1. Ang mga may hawak ng token, kasama ang mga tagapagpatunay, ay maaaring maglagay ng kanilang mga tokens na “**bonded**” sa taya. Ang mga may hawak ng token ay maaaring **magtalaga** ng kanilang mga tokens sa anumang tagapagpatunay o kandidatong tagapagpatunay, para asahan na maaari itong maging isang aktwal na tagapagpatunay, at sa paglaon maaari silang pumili ng ibang tagapagpatunay o kandidato para **muling magtalaga** ng kanilang mga tokens 1. 261 | 2. Ang lahat ng mga kandidatong tagapagpatunay ay mairaranggo base sa bilang ng mga bonded na token sa kanila, at ang nangungunang sa mga ito ay magiging totoong mga tagapagpatunay. 262 | 3. Maaaring ibahagi (bahagi ng) ng mga Tagapagpatunay ang kanilang gantimpala sa pag-bloke sa kanilang mga delegado. 263 | 4. Ang mga Tagapagpatunay ay maaaring magdusa mula sa “**Pagbawas**”, isang parusa para sa kanilang mga masamang pagkilos, tulad ng dobleng pagpirma at/o kawalang-tatag. Ang nasabing pagkawala ay ibabahagi pati na rin ng kanilang **mga delegado**. 264 | 5. Mayroong isang "**unboding na panahon**" para sa mga tagapagpatunay at delegado para masiguro ng sistema na ang mga tokens ay mananatiling naka-bond kapag nahuli ang mga masamang pagkilos, ang mananagot ay mababawasan sa panahong ito. 265 | 266 | ## Pagtaya sa BC 267 | 268 | Mas mainam na ang naturang lohika ng pagtaya at gantimpala ay dapat na parte na blockchain, at awtomatikong pinapatupad habang nangyayari ang pag-bloke. Ang Cosmos Hub, na nagbabahagi ng parehong Tendermint na pagkakasunduan at mga librerya sa BNB Beacon Chain, ay gumagana sa ganitong paraan. 269 | 270 | Naghahanda ang BC para paganahin ang lohika ng pagtaya mula pa noong mga araw ng pagdisenyo nito. Sa kabilang panig, tulad ng nais ng BSC na manatiling katugma sa Ethereum hangga't maaari, ito ay isang malaking hamon at pagsisikap na ipatupad ang naturang lohika dito. Totoo ito lalo na kapag ang Ethereum mismo ay maaaring lumipat sa ibang Patunay ng Taya na protokol ng pagkakasunduan sa isang maikling (o mas matagal) na oras. Upang mapanatili ang pagiging tugma at magamit ulit ang magandang pundasyon ng BC, ang lohika ng pagtyaa ng BSC ay ipinatupad sa BC: 271 | 272 | 1. Ang token sa pagtaya ay BNB, dahil ito ay isang katutubong token sa parehong mga blockchain gayon pa man 273 | 2. Ang pagtaya, ibig sabihin, token bond at pagkilos ng delegasyon at mga tala para sa BSC, ay nangyayari sa BC. 274 | 3. Ang hanay ng tagapagpatunay ng BSC ay natutukoy sa pamamagitan ng pagtaya at delegado na lohika, sa pamamagitan ng isang modyul ng pagtaya na itinayo sa BC para sa BSC, at pinalaganap araw-araw UTC 00:00 mula BC hanggang BSC sa pamamagitan ng Cross-Chain na komunikasyon. 275 | 4. Ang pamamahagi ng gantimpala ay nangyayari sa BC sa humigit-kumulang araw-araw UTC 00:00. 276 | 277 | ## Paggantimpala 278 | 279 | Parehong nangyayari ang pag-update ng tagapagpatunay at pamamahagi ng gantimpala araw-araw ng UTC 00:00. Ito ay para makatipid sa gastos ng madalas na mga pag-update ng staking at pamamahagi ng gantimpala ng bloke. Ang gastos na ito ay maaaring maging malaki, dahil ang gantimpala ng bloke ay nakokolekta sa BSC at ibinabahagi sa BC sa mga tagapagpatunay at delegado ng BSC. (Mangyaring tandaan na ang mga bayarin sa pag-bloke ng BC ay mananatiling makabuluhan sa mga tagapagpatunay lang ng BC.) 280 | 281 | Ang isang sadyang pagkaantala ay ipinakilala dito para matiyak na ang pamamahagi ay patas: 282 | 283 | 1. Ang gantimpala sa pag-bloke ay hindi ipapadala kaagad sa tagapagpatunay, sa halip, ipapamahagi at maiipon ito sa isang kontrata; 284 | 2. Sa pagtanggap ng itinatakdang pag-update ng tagapagpatunay sa BSC, mag-uudyok ito ng ilang mga cross-chain na paglipat para ilipat ang gantimpala sa mga address ng pangangalaga sa mga kaukulang tagapagpatunay. Ang mga address ng pangangalaga ay pag-aari ng sistema para hindi magastos ang gantimpala hangga't hindi nangyayari ang ipinangakong pamamahagi sa mga delegado. 285 | 3. Upang gawing mas simple ang sinkronisasyon at maglaan ng oras para mapaunlakan ang pagbawas, ang gantimpala para sa N na araw ay ibabahagi lang sa N+2 na araw. Matapos makuha ng mga delegado ang gantimpala, ililipat ang natira sa sariling mga address ng gantimpala ng mga tagapagpatunay. 286 | 287 | ## Pagbawas 288 | 289 | Ang pagbawas ay bahagi ng on-chain na pamamahala, para matiyak na ang mga nakakahamak o negatibong pagkilos ay maparusahan. Ang bawas sa BSC ay maaaring isumite ng sinuman. Ang pagsusumite ng transaksyon ay nangangailangan ng **ebidensya ng bawas** at mga bayarin sa gastos pero nagdadala din ng isang mas malaking gantimpala kapag ito ay matagumpay. 290 | 291 | Sa ngayon mayroong dalawang mga kaso na maaaring maisagawa ang pagbawas. 292 | 293 | ### Dobleng Pagpirma 294 | 295 | Ito ay lubos na seryosong kamalian at malamang ay sinadyang kasalanan kapag ang isang tagapagpatunay ay nagpirma ng higit sa isang bloke na may parehong taas at magulang na bloke. Ang implementasyon ng sanggunian na protokol ay dapat na meron ng lohika para maiwasan ito, kaya ang nakakahamak na kodigo lang ang maaaring mag-udyok nito. Kapag nangyari ang Dobleng Pagpirma, dapat alisin kaagad ang tagapagpatunay mula sa **Hanay** ng Tagapagpatunay. 296 | 297 | Ang sinuman ay maaaring magsumite ng isang hiling na pagbawas sa BC na may katibayan ng Dobleng Pagpirma ng BSC, na dapat maglaman ng 2 ulo ng bloke na may parehong taas at magulang na bloke, na tinatakan ng nagkasala na tagapagpatunay. Sa pagtanggap ng ebidensya, kung mapatunayan ito ng BC na totoo: 298 | 299 | 1. Ang tagapagpatunay ay aalisin mula sa hanay nito ng isang instansiya ng hanay ng tagapagpatunay ng BSC na update sa Cross-Chain; 300 | 2. Ang taya sa tagapagpatunay ay babawasan ng paunang natukoy na halaga; 301 | 3. Bahagi ng nabawasan na BNB ay ilalaan sa address ng nagsumite, na kung saan ay isang gantimpala at mas malaki kaysa sa gastos ng pagsumite ng transaksyon sa paghiling ng pagbawas 302 | 4. Ang natitirang nabawasan na BNB ay ilalaan sa ibang mga address na nasa pangangalaga ng mga tagapagpatunay, at ibabahagi sa lahat ng mga delegado sa parehong paraan ng gantimpala sa pag-bloke. 303 | 304 | ### Hindi Nagagamit 305 | 306 | Ang pagka aktibo ng BSC ay nakasalalay na lahat sa Patunay ng Itinayang Awtoridad na hanay ng tagapagpatunay ay makakagawa ng mga bloke ng napapanahon kapag pagkakataon na nila. Ang mga Tagapagpatunay ay maaaring makaligtaan ang kanilang pagkakataon dahil sa anumang kadahilanan, lalo na ang mga problema sa kanilang hardware, software, pagsasaayos o network. Ang kawalang-tatag ng operasyon na ito ay makakasakit sa kakayahang pagganap at magpapakilala ng higit na hindi matukoy na aspeto sa sistema. 307 | 308 | Maaaring may isang panloob na matalinong kontrata na responsable sa pagtatala ng mga hindi nasagot na sukatan ng pag-bloke ng bawat tagapagpatunay. Kapag ang mga sukatan ay nasa itaas na ng paunang natukoy na threshold, ang gantimpala sa pag-bloke para sa tagapagpatunay ay hindi maihahatid sa BC para sa pamamahagi pero ibabahagi sa iba pang mas mahusay na mga tagapagpatunay. Sa paraang iyon, ang tagapagpatunay na hindi maganda ang pagpapatakbo ay dapat na unti-unting iboto paalis mula sa itinakdang tagapagpatunay dahil ang kanilang mga delegado ay tatanggap ng mas kaunti o walang gantimpala. Kung ang mga sukatan ay mananatili sa itaas ng isa pang mas mataas na antas ng threshold, ang tagapagpatunay ay mahuhulog mula sa pag-ikot, at ito ay ikakalat pabalik sa BC kapag may isang Pagbawas na magaganap sa taya ng tagapagpatunay. 309 | 310 | ### Mga Parametro sa Pamamahala 311 | 312 | Maraming mga parametro ng sistema para makontrol ang pagkilos ng BSC, hal. halaga ng pagbawas, bayad sa cross-chain na paglipat. Ang lahat ng mga parametro na ito ay matutukoy ng BSC na Hanay ng Tagapagpatunay nang sama-sama sa pamamagitan ng proseso ng pagboto ng panukala batay sa kanilang pagtaya. Ang nasabing proseso ay isasagawa sa BC, at ang mga bagong halaga ng parametro ay kukunin ng kaukulang mga sistemang kontrata sa pamamagitan ng isang cross-chain na komunikasyon. 313 | 314 | # Mga Tagahatid 315 | 316 | Ang mga tagahatid ang responsable sa pagsumite ng mga Cross-Chain na Komunikasyon na Pakete sa pagitan ng dalawang mga blockchain. Dahil sa magkakaiba-ibang istraktura ng magkahanay na kadena, dalawang magkaibang uri ng Tagahatid ang nalikha. 317 | 318 | ## Mga Tagahatid ng BSC 319 | 320 | Ang mga tagahatid para sa komunikasyon ng BC patungo sa BSC ay tinatawag na mga “**Tagahatid ng BSC**”, o simpleng mga "Tagahatid". Ang Paghatid ay isang nakapag-iisang proseso na maaaring patakbuhin ng sinuman, at saanman, maliban na ang mga Tagahatid ay dapat magparehistro ng kanilang sarili sa BSC at magdeposito ng isang tiyak na naibabalik na halaga ng BNB. Ang mga kahilingan lang sa paghatid mula sa mga nakarehistrong Tagahatid ang tatanggapin ng BSC. 321 | 322 | Ang pakete na hinahatid nila ay papatunayan ng on-chain na magaan na kliyente sa BSC. Ang matagumpay na paghatid ay kailangang pumasa sa sapat na pagpapatunay at may gastos na mga bayarin sa gas sa BSC, at sa gayon ay dapat mayroong gantimpalang insentibo para mahikayat ang komunidad na magpatakbo ng mga Tagahatid. 323 | 324 | ### Mga Insentibo 325 | 326 | Mayroong dalawang pangunahing uri ng komunikasyon: 327 | 328 | 1. Mga Operasyon na inudyok ng mga user, tulad ng `token bind` o `cross chain transfer`. Dapat magbayad ang mga user ng karagdagang bayad bilang gantimpala ng tagahatid. Ibabahagi ang gantimpala sa mga tagahatid na nagsisink sa mga natukoy na mga ulo ng blockchain. Bukod, ang gantimpala ay hindi mababayaran nang direkta sa mga account ng mga tagahatid. Ipapatupad ang isang mekanismo ng pamamahagi ng gantimpala para maiwasan ang monopolisasyon. 329 | 2. Sinkronisasyon ng Sistema, tulad ng paghahatid ng `refund package` (sanhi ng mga pagkabigo ng karamihan sa mga orakulong tagahatid), espesyal na sinkronisasyon ng ulo ng blockchain (ang ulo ay naglalaman ng pag-update ng hanay ng tagapagpatunay ng BC), pakete ng pagtaya ng BSC. Ang kontrata ng gantimpala ng sistema ay magbabayad ng gantimpala sa mga account ng mga tagahatid nang direkta. 330 | 331 | Kung ang ilang mga Tagahatid ay may mas mabilis na mga network at mas mahusay na hardware, maaari nilang i-monopolyo ang lahat ng paghatid ng pakete at walang maiiwan na gantimpala sa iba. Sa gayon mas kaunting mga kalahok ang sasali para sa paghatid, na hihikayat ng sentralisasyon at pipinsala sa kahusayan at seguridad ng network. Mas mainam, dahil sa desentralisasyon at dinamikong muling halalan ng mga tagapagpatunay ng BSC, ang isang Tagahatid ay maaaring hindi palaging ang una na maghatid ng bawat mensahe. Pero para maiwasan ang karagdagang monopolisasyon, ang ekonomiya ng paggantimpala ay espesyal din na idinisenyo para mabawasan ang nasabing pagkakataon: 332 | 333 | 1. Ang gantimpala para sa mga Tagahatid ay ibabahagi lang ayon sa pagkapangkat, at ang isang pangkat ang sasaklaw sa isang bilang ng mga matagumpay na naihatid na pakete. 334 | 2. Ang gantimpala na maaaring makuha ng isang Tagahatid mula sa isang pamamahagi sa pagkapangkat ay hindi tuwid ang proporsyon sa bilang ng kanilang mga matagumpay na naihatid na pakete. Sa halip, maliban sa unang ilang mga paghatid, kapag mas maraming naihatid ang isang Tagahatid sa panahon ng isang pangkat, mas kaunting gantimpala ang makokolekta nito. 335 | 336 | ## Mga Orakulong Tagahatid 337 | 338 | Ang mga tagahatid para sa komunikasyon ng BSC patungo sa BC ay gumagamit ng modelong "Orakulo", at tinaguriang mga “**Orakulong Tagahatid**”. Ang bawat isa sa mga tagapagpatunay ay dapat, at ang nasa hanay ng tagapagpatunay lang, ang magpatakbo ng mga Orakulong Tagahatid. Pinapanood ng bawat Orakulong Tagahatid ang pagbabago ng estado ng blockchain. Kapag nahuli nito ang Mga Pakete ng Cross-Chain na Komunikasyon, isusumite ito para bumoto para sa mga kahilingan. Pagkatapos ng mga Orakulong Tagahatid mula sa ⅔ ng kapangyarihan sa pagboto ng mga tagapagpatunay ng BC na bumoto para sa mga pagbabago, isasagawa ang mga pagkilos na cross-chain. 339 | 340 | Dapat maghintay ang Orakulong Tagahatid para sa sapat na mga bloke para kumpirmahin ang kawakasan sa BSC bago magsumite at bumto para sa mga cross-chain na pakete ng komunikasyon patungoo sa BC. 341 | 342 | Ang mga bayarin sa cross-chain ay ibabahagi sa mga tagapagpatunay ng BC kasama ang normal na mga gantimpala sa pag-bloke sa BC. 343 | 344 | Ang nasabing orakulong uri ng paghatid ay nakasalalay sa lahat ng mga tagapagpatunay na suportahan. Dahil ang lahat ng mga boto para sa mga pakete ng cross-chain na komunikasyon ay naitala sa blockchain, hindi mahirap magkaroon ng isang panukat na sistema para masuri ang kakayahan sa pagganap ng mga Orakulong Tagahatid. Ang pinakamahinang tagaganap ay maaaring ang kanilang mga gantimpala ay kalmutin pabalik sa pamamagitan ng isa pang Pagbawas na lohika na ipinakilala sa hinaharap. 345 | 346 | # Pananaw 347 | 348 | Mahirap magtapos para sa BNB Beacon Chain, dahil hindi ito tumitigil sa pag-unlad. Ang diskarte sa dalawahang kadena ay para buksan ang pintuan para sa mga user para samantalahin ang mabilis na paglilipat at pakikipagkalakalan sa isang panig, at may kakayahang umangkop at napapalawak na pag-program sa kabilang panig, pero ito ay magiging isang hintuan sa pagbuo ng BNB Chain. Nasa ibaba ang mga paksang maaaring tingnan para mas mapadali ang komunidad para sa mas higit pa na kakayahang magamit at mapalawak: 349 | 350 | 1. Magdagdag ng iba't ibang modelo ng digital na asset para sa iba't ibang mga kaso ng paggamit sa negosyo 351 | 2. Paganahin ang mas marami pang pinagkukunan ng mga datos, lalo na ang mga datos ng merkado ng DEX, na ipaparating mula sa BNB Beacon Chain DEX patungo sa BSC 352 | 3. Magbigay ng interface at pagiging tugma para ma-integrate sa Ethereum, kasama ang karagdagang pagsulong, at iba pang blockchain 353 | 4. Pagbutihin ang karanasan sa panig ng kliyente sa pangangasiwa ng mga pitaka at sa mas madaling paggamit ng blockchain 354 | 355 | 356 | 357 | ------ 358 | 359 | [1]: Ang mga propesyonal sa negosyo sa BNB ay maaaring magbigay ng iba pang mga benepisyo para sa mga delegado ng BNB, tulad ng ginagawa nila ngayon para sa mga pangmatagalang may hawak ng BNB. 360 | -------------------------------------------------------------------------------- /translations/Whitepaper_ BNB Smart Chain_spanish_translation_VIOLA.md: -------------------------------------------------------------------------------- 1 | BNB Smart Chain: Una cadena de bloques paralela de BNB Beacon Chain orientada a posibilitar Contratos Inteligentes 2 | 3 | Versión 0.1 4 | 5 | 2020/04/17 6 | 7 | Traducción: 8 | 9 | PhD. Federico Ignacio Viola 10 | 11 | 2020/11/18 12 | 13 | # Motivación 14 | 15 | Después de su lanzamiento en la mainnet comunitaria en abril de 2019, BNB Beacon Chain ha exhibido una alta velocidad y un diseño de alto rendimiento. El foco primario de la cadena de bloques de BNB, su aplicación nativa descentralizada ("dApp") BNB DEX, ha demostrado baja latencia en correspondencia con su margen de gran capacidad de gestión en poco tiempo de un volumen millonario de transacciones. 16 | 17 | Flexibilidad y usabilidad están a menudo en relación inversa respecto del desempeño. Puesto el foco en proveer el espacio conveniente para emitir y negociar activos digitales trae también consigo limitaciones La característica más requerida para la cadena de bloques BNB es la extensibilidad programable o simplemente las funciones de contratos inteligentes y máquinas virtuales. Los emisores y propietarios de activos se esfuerzan para agregar nuevas funciones descentralizadas para dichos activos o para introducir cualquier forma de gobernanza y actividades comunitarias. 18 | 19 | A pesar de la alta demanda de introducir la función de contratos inteligentes en la BNB Beacon Chain, no se trata de una decisión fácil de tomar La ejecución de un contrato inteligente podría ralentizar la función de intercambio y sumar un factores no deterministas a las negociaciones. Si se pudiera ser tolerante y ceder, la idea más sencilla sería introducir una nueva especificación de máquina virtual basada en Tendermint, basada en el actual protocolo de consenso subyacente y la implementación principal RPC de la BNB Beacon Chain. Pero todo esto incrementaría los requerimientos de aprendizajes para todas las comunidades dApp existentes y no sería muy bienvenido. 20 | 21 | Proponemos una blockchain que sea paralela a la actual BNB Beacon Chain para mantener el alto rendimiento de la blockchain DEX y para respaldar, al mismo tiempo, una función amigable de contratos inteligentes. 22 | 23 | # Criterios de Diseño 24 | 25 | Después de la creación de la blockchain paralela en el ecosistema de la BNB Beacon Chain, dos cadenas de bloques operarán una junto a la otra para proporcionar diferentes servicios. La nueva cadena paralela se llamará "**BNB Smart Chain**" (abreviada **"BSC" para las secciones posteriores**), mientras que la mainnet existente continuará siendo denominada "**BNB Beacon Chain**" (abreviada **"BC" para las secciones posteriores**). 26 | 27 | He aquí los principios de diseño de la BSC: 28 | 29 | 1. **Blockchain autónoma**: técnicamente la BSC es una blockchain independiente en vez de una solución de dos capas. La mayoría de las funciones fundamentales, técnicas y comerciales, de la BSC deben ser autosuficientes de manera que puedan funcionar correctamente aún si la BC se detuviera por un breve período de tiempo. 30 | 2. **Compatibilidad con Ethereum**: la primera plataforma ampliamente utilizada y funcional de contratos inteligentes es Ethereum. Para sacar provecho de sus aplicaciones que poseen una relativa madurez y de su comunidad, se decide que la BSC sea compatible con la actual mainnet de Ethereum. Esto significa que la mayoría de sus **dApps**, componentes de ecosistema e instrumental funcionarán sobre la BSC y requerirán mínima o ninguna alteración; el nodo BSC requerirá de una especicación y de unas habilidades de operación y ejecución de hardware similar (o apenas superior) para funcionar y operar. La implementación de la BSC deberá permitir que ésta pueda ponerse al día con actualizaciones adicionales de Ethereum. 31 | 3. **Consenso y gobernanza implicados en el staking**: el consenso basado en el staking es más amigable con el medioambiente y permite opciones más flexibles para la gobernanza comunitaria. Según lo esperado, este consenso debe permitir un mejor rendimiento de la red respecto de la prueba de trabajo (proof-of-work) plena, es decir, tiempo de bloqueo más rápido y mayor capacidad de transacción. 32 | 4. **Comunicación entrecruzada nativa de cadenas de bloques**: tanto BC como BSC se escribirán con soporte nativo para comunicación entrecruzada de cadenas entre las dos blockchains. El protocolo de comunicación debe ser bidireccional, descentralizado y no basado en confianza. Se focalizará en mover activos digitales entre BC y BSC, es decir, tokens BEP2, y llegado el caso, algún otro token BEP introducido con posterioridad. El protocolo debe ocuparse mínimamente de otros items almacenados en el estado de la blockchain, con sólo unas pocas excepciones. 33 | 34 | # Consenso y quorum de validación 35 | 36 | Basado en los principios de diseño arriba mencionados, el protocolo de consenso en la BSC debe cumplir con los siguientes objetivos: 37 | 38 | 1. El tiempo de bloqueo debe ser más breve que el de Ethereum, por ejemplo, cinco segundos o incluso menos. 39 | 2. Requiere un tiempo limitado para confirmar la finalización de las transacciones, a saber, alrededor de un minuto o menos. 40 | 3. No debe tener inflación, la recompensa por bloque se toma de las tarifas de gas y el gas se pagará en BNB. 41 | 4. Permite compatibilidad del sistema con Ethereum tanto como sea posible. 42 | 5. Provee una red de gobernanza moderna basada en staking. 43 | 44 | ## Prueba de autoridad participada 45 | 46 | Aunque la Prueba de trabajo (Proof-of-Work - PoW) ha sido aceptada como un mecanismo práctico para implementar una red descentralizada, no es amigable con el medioambiente y requiere además un gran número de participantes para mantener la seguridad. 47 | 48 | Ethereum y algunas otras redes tales como MATIC Bor, TOMOChain, GoChain, xDAI, usan Prueba de Autoridad (Proof-of-Authority - PoA) o sus variantes en diferentes escenarios, incluidas la testnet así como la mainnet. La PoA proporciona alguna defensa contra el ataque del 51%, con eficiencia mejorada y con tolerancia para un cierto nivel de actores bizantinos (maliciosos o hackeados). Funciona como una opción fundamental fácil de escoger. 49 | 50 | Mientras tanto, el protocolo PoA es el más criticado por no ser tan descentralizado como el de PoW, puesto que los validadores, es decir, los nodos que se turnan para producir bloques, tienen todos autoridad y son propensos a la corrupción y a los ataques contra la seguridad. Otras blockchains tales como EOS y Cosmos introducen ambas diferentes tipos de prueba de participación delegada (Delegated Proof of Stake - DPoS) para permitir votar a los tenedores de tokens y elegir el grupo validador. Esto incrementa la descentralización y favorece la gobernanza comunitaria. 51 | 52 | Aquí se propone que en BSC se combine DPoS y PoA para consenso, de manera que: 53 | 54 | 1. Los bloques sean producidos por un grupo limitado de validadores. 55 | 2. Los validadores se turnen para producir bloques a la manera PoA, similar a Clique, el motor de consenso de Ethereum. 56 | 3. El grupo de validadores sea elejido dentro y fuera en función de una gobernanza basada en la participación. 57 | 58 | ## Quorum de validación 59 | 60 | En la etapa genética, unos pocos nodos de confianza operarán como el grupo de validación inicial. Luego de que comienza la producción de bloques, cualquiera puede competir para unirse como candidato para elegir como validador. El estado del staking decide cuál de los 21 nodos con más alta participación ha de ser el próximo grupo validador y dicho tipo de elección se repetirá cada 24 horas. 61 | 62 | **BNB **es el token utilizado para el staking para la BSC. 63 | 64 | En orden a permanecer tan compatible como Ethereum y actualizable respecto de futuros protocolos de consenso a ser desarrollados, se opta por que BSC dependa de la **BC **para la gestión del staking (consultar la siguiente sección "Staking y gobernanza"). Hay un **módulo dedicado de staking para BSC en la BC**. Dicho módulo aceptará el BSC staking de los tenedores de BNB y calculará el grupo de nodos con la más alta participación Cada medianoche en tiempo UTC, BC emitirá un mensaje "ValidatorSetUpdate" entrecruzado de cadenas verificable para notificar a la BSC para que actualice su grupo validador. 65 | 66 | Mientras se producen bloques adicionales, los validadores de la BSC existentes comprobarán si hay un mensaje "ValidatorSetUpdate" de los que se transmiten periódicamente a la BSC. Si lo hay, actualizarán el grupo validador luego de un **período de época**, es decir, luego de un número predefinido de tiempo de producción de bloques Por ejemplo, si la BSC produce un bloque cada cinco segundos y si el período de época es de 240 bloques, entonces el grupo validador actual comprobará y actualizará el grupo validador para la época siguiente en 1200 segundos (20 minutos). 67 | 68 | ## Seguridad y finalización 69 | 70 | Dado que hay más de ½ * N + 1 de validadores honestos, las redes basadas en PoA generalmente funcionan correctamente y de forma segura. Sin embargo, aún hay casos en los que cierta cantidad de validadores bizantinos podrían incluso lograr atacar la red, por ejemplo, a través de un "[ataque de clones](https://arxiv.org/pdf/1902.10244.pdf)". Para que la BSC sea tan segura como la BC, se incentiva a los usuarios a esperar hasta recibir los bloques estampados por más de los ⅔ * N + 1 de los diferentes validadores De esa maera, se puede confiar en la BSC a un nivel similar de seguridad que el de la BC ya que puede tolerar menos de ⅓ * N de validadores bizantinos 71 | 72 | Con 21 validadores, si el tiempo por bloque es de cinco segundos, los ⅔ * N + 1 de los estampados de los diferentes validadores requerirán un período de tiempo de (⅔ * 21 + 1) * 5 = 75 segundos. Cualquier aplicación crítica para BSC tendrá que poder esperar ⅔ * N + 1 para garantizar una finalización relativamente segura. Sin embargo, aparte de tal disposición, la BSC introduce una lógica de **recorte **para penalizar a los validadores bizantinos cuando incurran en **doble firma **o por **inestabilidad**, cuestión que se tratará más adelante en la sección "Staking y gobernanza". Esta lógica de corte expondrá a los validadores maliciosos rápidamente y hará muy difícil un "ataque de clones" o hará que su ejecución sea de un costo económico totalmente inconveniente. Con esta mejora, ½ * N + 1 o incluso una menor cantidad de bloques son suficientes como confirmación para la mayoría de las transacciones. 73 | 74 | ## Recompensa 75 | 76 | Todos los validadores de la BSC en el grupo actual de validadores serán recompensados con **tarifas **de transacción de gas **en BNB**. Como BNB no es un token inflacionario, no habrá recompensas de minería como las que se generan en la red Bitcoin y Ethereum, y la tarifa de gas representa la principal recompensa para los validadores. Como BNB constituye también un token de utilidad con otros casos de uso, delegadores y validadores seguirán aún disfrutando de otros beneficios como tenedores de BNB. 77 | 78 | La recompensa para validadores la constituye la tarifa de gas que se recoge por las transacciones en cada bloque. La validadores pueden decidir cuánto devolver a los delegadores que hacen staking de BNB para ellos, de manera de hacer más atractivo el staking con ellos. Cada validador se turnará para producir los bloques con la misma probabilidad (si adhieren al 100% de liveness), por lo que, a largo plazo, todos los validadores estables pueden obtener una recompensa de similar magnitud. Mientras tanto, el riesgo en cada validador podría diferir, lo que conduce a una situación contraintuitiva que consiste en que cuanto más usuarios confían y delegan a un solo validador, obtienen potencialmente menos recompensa. De manera que, razonablemente, los delegadores tenderán a delegar en aquél que tenga menos participaciones siempre y cuando el validador sea todavía de fiar (un validador inseguro conllevaría un riesgo de corte). Finalmente, las participaciones (staking) en todos los validadores tendrá menor variación. Esto evitará efectivamente la concentración del staking y el problema de que el "ganador siempre gana" como sucede en algunas otras redes. 79 | 80 | Una porción de la tarifa de gas también irá como recompensa a los "transmisores" encargados de la comunicación entrecruzada de cadenas de bloques. Consultar la sección "Transmisores" más abajo. 81 | 82 | # Economía de tokens 83 | 84 | BC y BSC comparten el mismo universo de tokens para los tokens BNB y BEP2 Esto determina lo siguiente: 85 | 86 | 1. El mismo token puede circular en ambas redes y circular entre ellas de manera bidireccional a través de un mecanismo de comunicación entrecruzada de cadena de bloques. 87 | 2. La circulación total del mismo token debe ser gestionada a lo largo de las dos redes, es decir que la provisión total efectiva de un token debe ser la suma de la provisión total efectiva del token tanto en la BSC como en la BC. 88 | 3. Los tokens pueden ser creados inicialmente en la BSC en un formato similar al ERC20, o bien en la BC como un BEP2 y luego ser creados en la otra. Hay formas nativas que vinculan ambas redes y aseguran la provisión total del token. 89 | 90 | ## Token Nativo 91 | 92 | BNB se ejecutará en la BSC de la misma forma que ETH se ejecuta en Ethereum, de manera que continúe siendo un "token nativo" tanto para la BSC como para la BC. Esto siginifica por lo demás que BNB, utilizado para pagar la mayoría de las tarifas en BNB Beacon Chain y BNB DEX, se utilizará ademas para: 93 | 94 | 1. pagar "gas" para implementar contratos inteligentes en la BSC. 95 | 2. hacer staking respecto de validadores BSC escogidos y obtener las recompensas correspondientes. 96 | 3. llevar a cabo operaciones entrecruzadas de cadenas de bloques, tales como transferir activos tokens entre BC y BSC. 97 | 98 | ### Fondo germinal 99 | 100 | Ciertas cantidades de BNB serán incineradas en la BC y acuñadas en la BSC durante su etapa de génesis. Este monto se denomina "Fondo germinal", destinado a circular en la BSC después del primer bloque y que será enviado al transmisor (relayer) BC-a-BSC inicial (descrito más adelante) y al grupo validador inicial introducido en la etapa de génesis. Estos BNBs se utilizan para pagar tarifas de transacción en la fase inicial para transferir más BNB desde la BC hacia la BSC a través de un mecanismo entrecruzado de cadena de bloques. 101 | 102 | La transferencia entrecruzada de cadena de bloques será discutida en una sección posterior, pero para la transferencia de BC a BSC generalmente se debe bloquear BNB en la BC desde la dirección de origen de la transferencia hacia una dirección de sistema controlado y desbloquear el monto correspondiente del contrato especial hacia la dirección de transferencia en la BSC, o a la inversa, cuando se transfiere de la BSC a la BC, hay que bloquear BNB desde la dirección de origen en la BSC en un contrato especial y liberar el monto bloqueado en la BC desde la dirección del sistema hacia la dirección de destino. La lógica está relacionada con un código nativo en la BC y con una serie de contratos inteligentes en la BSC. 103 | 104 | ## Otros tokens 105 | 106 | BC admite tokens BEP2 y los futuros [tokens BEP8 ](https://github.com/bnb-chain/BEPs/pull/69)que son activos nativos transferibles y negociables (una vez enlistados) mediante transacciones rápidas y con un tiempo de finalización inferior a un segundo Mientras tanto, como la BSC es compatible con Ethereum, es lógico admitir tokens ERC20 en ella, los mismos se denominarán aquí "**BEP2E**" (con el nombre real que será introducido por los futuros BEPs potencialmente también abarcará asimismo el BEP8). BEP2E podría ser "mejorado" agregandole algunos pocos métodos para exhibir más información como ser la denominación del token, la definición de precisión decimal y la dirección del propietario que puede decidir el enlace del token (Token Binding) a lo largo de las cadenas. BSC y BC trabajan juntas para garantizar que un token pueda circular en ambos formatos con una provisión total confirmada y ser utilizados en diferentes casos de usos. 107 | 108 | ### Enlace de Tokens 109 | 110 | Los tokens BEP2 serán extendidos en orden a albergar un nuevo atributo que asocie el token con un contrato de token BSC BEP2E, llamado "**enlazador**" (Binder), y el proceso de asociación se denomina "vinculación de tokens". 111 | 112 | La vinculación de tokens puede ocurrir en cualquier momento una vez que BEP2 y BEP2E están listos. Los propietarios del token ya sea éste BEP2 o BEP2E no necesitan preocuparse por la vinculación, hasta antes de que realmente quieran usar los tokens en diversos escenarios. Los emisores pueden crear primero tokens BEP2 o primero BEP2E y pueden vincularlos con posterioridad. Por supuesto que se busca incentivar a todos los emisores de BEP2 y de BEP2E a que configuren el enlace poco después de su emisión. 113 | 114 | Un procedimiento típico para enlazar BEP2 y BEP2E sería como lo que sigue: 115 | 116 | 1. Garantizar de que tanto el token BEP2 como el BEP2E existan en cada cadena de bloques con la misma provisión total. BEP2E debería tener tres métodos más que el típico ERC20: 117 | 118 | a. symbol(): obtiene el símbolo de token. 119 | 120 | b. decimals(): obtiene el número de dígitos decimales del token 121 | 122 | c. owner(): obtiene **la dirección del propietario del contrato de vinculación**. Este valor debe ser inicializado en el constructor del contrato BEP2E de manera que la acción de enlace adicional pueda verificar si el enlazamiento obtiene el consentimiento del propietario BEP2E. 123 | 124 | 1. Decidir la circulación inicial en ambas cadenas de bloques. Dado el supuesto que la provisión total sea *S *, y la expectativa inicial de circulación en la BC sea *K*, en consecuencia el propietario tiene que bloquear S-K tokens en una dirección controlada por sistema en la BC. 125 | 2. De manera equivalente, una cantidad *K *de tokens serán bloqueados en un contrato especial en la BSC, el cual se ocupará de las principales funciones de enlazamiento. El mismo es conocido como **TokenHub**. El emisor del token BEP2E debe bloquear el monto *K *de ese token en el TokenHub, resultando en *S-K *tokens para circular en la BSC. De ese modo la circulación total a lo largo de las dos cadenas de bloques permanece como *S*. 126 | 3. El emisor de tokens BEP2 envía la transacción de enlazamiento en la BC. Una vez que la transacción es ejecutada con éxito luego de una verificación adecuada: 127 | 128 | a. Transfiere S-K tokens a una dirección controlada por sistema en la BC. 129 | 130 | b. Se creará un paquete de petición de enlace de entrecruzamiento de cadena de bloques, esperando a que lo transmisores (relayers) lo transmitan. 131 | 132 | 1. Los transmisores de la BSC pasarán el paquete de petición de enlace de entrecruzamiento de cadena de bloques al TokenHub en la BSC y la correspondiente petición e información se almacenarán en el contrato. 133 | 2. El propietario del contrato y sólo él puede ejecutar un método especial de contrato TokenHub, denominado ApproveBind, para verificar la petición de entrelazamiento de manera de calificarla como exitosa. Así se confirmará: 134 | 135 | a. que el token no logró el entrelazamiento; 136 | 137 | b. el entrelazamiento es para el símbolo apropiado, con la provisión total apropiada y la información sobre los decimales. 138 | 139 | c. los bloqueos correspondientes se realizan en ambas redes; 140 | 141 | 1. Una vez que el método ApproveBind ha sido exitoso, el TokenHub señalará que los dos tokens están entrelazados y asignará la misma circulación en la BSC y propagará dicho estatus de vuelta en la BC. Después de esta confirmación final, la dirección del contrato BEP2E y los decimales se escribirán en el token BEP2 como un nuevo atributo en la BC y los tokens podrán ser transferidos bidireccionalmente entre las dos cadenas de bloques. Si el ApproveBind fracasa, el evento fallido también será propagado de vuelta a la BC para liberar los tokens bloqueados y los pasos arriba nombrados podrán ser más tarde reiterados. 142 | 143 | # Comunicación y transferencia entrecruzada entre cadenas de bloques 144 | 145 | La comunicación entrecruzada entre cadenas de bloques es la clave fundamental que permite que la comunidad aproveche la estructura de cadena de bloques dual: 146 | 147 | - Los usuarios son libres de crear cualquier tipo de tokens, productos financieros y activos digitales en la bSC o en la BC según lo deseen; asimismo, 148 | - Los productos en la BSC pueden ser comerciados y distribuidos de forma manual y programáticamente negociados y puestos en circulación en el ambiente ultra-rápido, amigalbe, estable y de alto rendimiento de la BC; de la misma manera, 149 | - los usuarios pueden realizar estas operaciones a través de una interfaz de usuario y de un variado ecosistema de herramientas. 150 | 151 | ## Transferencia entrecruzada entre cadenas de bloques 152 | 153 | La transferencia entrecruzada entre cadenas de bloques es la forma clave de comunicación entre las dos blockchains. Esencialmente la lógica es: 154 | 155 | 1. la cadena de bloques de transferencia de salida bloqueará el monto de las direcciones del propietario de origen en una dirección/contrato controlado por sistema. 156 | 2. la cadena de bloques de transferencia de entrada desbloqueará el monto de la dirección/contrato controlada por sistema y lo enviará a las direcciones de destino. 157 | 158 | El mensaje del paquete de transferencia de entrecruzamiento de cadenas de bloques debería permitirles verificar a los transmisores BSC y a los transmisores oráculo BC: 159 | 160 | 1. Que una cantidad suficiente de activos de tokens son eliminados de la dirección de origen y bloqueados en una dirección/contrato controlado por sistema en la cadena de bloques de origen. Y que esto puede ser confirmado en la cadena de bloques de destino. 161 | 2. Que se libera el monto adecuado de activos tokens de una dirección/contrato controlado por sistema y que se asignan a las direcciones destinadas en la cadena de bloques de destino. Si hay una falla, debe poder ser confirmada en la cadena de bloques de origen, de manera que el token bloqueado pueda ser liberado de vuelta (esto podría acarrear un costo). 162 | 3. La suma de la circulación total de los activos de token en las dos cadenas de bloques no cambia luego de que se cumple esta acción de transferencia; no importa si la transferencia es exitosa o no. 163 | 164 | ![cross-chain](../assets/cross-chain.png) 165 | 166 | La arquitectura de comunicación entrecruzada entre cadenas es como está representada en el diagrama aquí arriba. Para adaptar ambos sistemas heterónomos, el manejo de la comunicación difiere en cada dirección. 167 | 168 | ## Arquitectura BC hacia BSC 169 | 170 | BC es una cadena de bloques de finalización instantánea basada en Tendermint. Validadores con al menos ⅔ * N + 1 del poder total de voto firmarán conjuntamente cada bloque de la cadena. De manera que sea práctico verificar el bloque de transacciones e incluso el valor de su estado a través del tipo de verificación de **Encabezado de Bloque **y de **Prueba de Merkle**. Esto ha sido investigado e implementado como "**Protocolo de cliente-ligero en cadena**", el cual ha sido intensamente discutido en la [comunidad Ethereum](https://github.com/ethereum/wiki/wiki/Light-client-protocol), así como estudiado e implementado para [la comunicación inter-cadenas de Cosmos](https://github.com/cosmos/ics/blob/a4173c91560567bdb7cc9abee8e61256fc3725e9/spec/ics-007-tendermint-client/README.md). 171 | 172 | La comunicación desde BC-hacia-BSC será verificada por un "**cliente ligero en cadena**" implementado a través de **contratos inteligentes** BSC (algunos de los cuales estarán "**pre-compilados**"). Luego que algunas transacciones y cambios de estados tienen lugar en la BC, si se define una transacción para activar la comunicación entre cadenas, los **transmisores **crearán y pasarán el mensaje de "**paquete**" entre cadenas y lo enviarán a la BSC como datos en los "contratos de clientes livianos". El cliente liviano verificará el paquete y ejecutará las transacciones si pasa la verificación. La verificación estará garantizada según el siguiente diseño: 173 | 174 | 1. El estado de bloqueo de la BC se sincronizará con los contratos del cliente liviano en la BSC de cuando en cuando, a través del encabezado de bloque y los pre-commits, para obtener la siguiente información: 175 | 176 | a. bloque y hash de la aplicación de la BC que están firmados por validadores. 177 | 178 | b. grupo de validadores actual y actualización del grupo de validadores. 179 | 180 | 1. El valor clave de la cadena de bloques se verificará en función de la prueba de Merkle y de la información que se nombra más arriba en el punto #1. 181 | 182 | Después de confirmar que el valor clave es exacto y confiable, los contratos del cliente liviano ejecutarán las acciones correspondientes para los paquetes de cadenas entrecruzadas. Algunos ejemplos de tales paquetes que pueden ser creados de BC-para-BSC son: 183 | 184 | 1. Entrelazamiento: entrelazado de tokens BEP2 y BEP2E 185 | 2. Transferencia: se transfieren tokens luego del entrelazamiento, lo que significa que la circulación disminuirá (será bloqueada) en la BC y aparecerá en el saldo de la dirección de destino en la BSC. 186 | 3. Manejo de errores: sirve para manipular cualquier evento de caducidad/falla en la comunicación BSC-hacia-BC. 187 | 4. Actualización del grupo de validadores BSC 188 | 189 | Para garantizar que no haya duplicaciones, una secuencia de mensajes adecuada y se dé una expiración a tiempo, existe un concepto de "canal" introducido en la BC para manipular cualquier tipo de comunicación. 190 | 191 | Para la cuestión de los transmisores, por favor remitirse también más abajo a la sección "Transmisores". 192 | 193 | ## Arquitectura BSC a BC 194 | 195 | BSC utiliza el protocolo de consenso de Prueba de Autoridad Participada, el cual tiene la posibilidad de bifurcación (fork) y requiere confirmación de más bloques. Un bloque sólo tiene la firma de un validador, de manera que no es conveniente depender de un sólo bloque para verificar los datos de la BSC. 196 | 197 | Para aprovechar al máximo el quórum de validación de la BC, se adopta una idea similar a muchas blockchains oráculos o [puente](https://github.com/poanetwork/poa-bridge): 198 | 199 | 1. Las solicitudes de comunicación de entrecruzamiento de cadenas de la BSC se enviarán y ejecutarán en la BSC en forma de transacciones. La ejecución de la transacción emitira eventos, los cuales se pueden observar y empaquetar en ciertos "**oráculos**" en la BC. En lugar de encabezados de bloque, hashes y pruebas de Merkle, este tipo de paquetes de "oráculo" contiene directamente la información de entrecruzamiento de cadenas para determinadas acciones. Información tal como remitente, destinatario y monto a transferir. 200 | 2. Para garantizar la seguridad del oráculo, los validadores de la BC formarán otro quórum de "**oráculos transmisores**". Cada validador de la BC debe ejecutar un **proceso dedicado **en la forma de un oráculo transmisor. Estos oráculos transmisores enviarán y votarán respecto del paquete de comunicación entrecruzada de cadenas, en tanto oráculos, en la BC utilizando las mismas claves de validación. Cualquier paquete firmado según el poder de voto de más de ⅔ * N + 1 de los transmisores oráculos será tan seguro como cualquier bloque firmado por el mismo quorum de los ⅔ * N + 1 del poder de voto de los validadores. 201 | 202 | Al utilizar el mismo quórum de validación, guarda tanto el código del cliente liviano como las actualizaciones continuas de bloques en la BC. Dichos oráculos tienen también IDs así como una tipología determinada, para garantizar secuenciación y manipulación adecuada de errores. 203 | 204 | ## Expiración y manejo de errores 205 | 206 | Hay escenarios en los que la comunicación entrecruzada de cadenas falla. Por ejemplo, el paquete enviado no puede ser ejecutado en la BSC debido a algún error de programación en el contrato. **Las lógicas de manejo de un error o una expiración **es utilizada en tales escenarios. 207 | 208 | Para los errores de usuario y sistema reconocibles o para cualquier excepción previsible, las dos redes deben rehabilitarse por sí mismas. Por ejemplo, cuando una transferencia de BC hacia BSC falla, la BSC comunicará un evento de falla y los oráculos transmisores ejecutarán un reembolso en la BC; cuando una transferencia de BSC hacia BSC falle, la BC emitirá un paquete de reembolso para ser enviado por los transmisores para desbloquear los fondos. 209 | 210 | Sin embargo, errores o excepciones imprevistas podrían todavía ocurrir en cualquiera de los pasos de la comunicación entrecruzada de cadenas. En cuyo caso, los transmisores y los oráculos transmisores se percatarán de que el correspondiente canal de entrecruzamiento de cadenas está atascado en una secuencia determinada. Luego de un período de expiración, los transmisores y los oráculos transmisores pueden requerir una transacción "SkipSequence" y la secuencia atascada será marcada como "Unexecutable". Se generará la alerta correspondiente y la comunidad deberá discutir como manejar dicho escenario; por ejemplo un reembolso a través del espónsor de los validadores o incluso una clarificación de los fondos bloqueados por error durante la siguiente actualización de la red. 211 | 212 | ## Entrecruzamiento de cadenas de bloques y experiencia de usuario 213 | 214 | Idealmente, los usuarios esperan utilizar dos cadenas de bloques paralelas de la misma manera que usan una sola. Lo cual requiere añadir más tipos de transacciones agregadas a la comunicación entre cadenas de manera que esto sea posible, lo cual suma una gran complejidad, un acoplamiento estrecho y una sobrecarga en el mantenimiento. Aquí la BC y la BSC sólo implementan las operaciones básicas en orden a posibilitar el flujo de valor en el lanzamiento inicial y dejar la mayor parte de la tarea que concierne a la experiencia de usuario del lado de la UI del cliente, como ser el caso las carteras de criptomonedas (wallets). Por ejemplo una magnífica cartera de criptomonedas debería permitir a los usuarios vender un token desde la BSC directamente en el libro de órdenes DEX de la BC de forma segura. 215 | 216 | ## Evento de contrato en cadenas de bloques entrecruzadas 217 | 218 | Un evento de contrato en una cadena de bloques entrecruzadas (CCCE) está diseñado para permitir que un contrato inteligente active transacciones de cadenas de bloques entrecruzadas directamente a través del código del contrato. Esto es posible en base a que: 219 | 220 | 1. Los contratos estándar del sistema pueden ser ofrecidos para cumplir con operaciones invocadas por contratos inteligenes generales. 221 | 2. Los eventos estándar pueden ser emitidos por contratos estándar; 222 | 3. Los oráculos transmisores pueden capturar los eventos estándar y activar las correspondientes operaciones de cadenas de bloques entrecruzadas. Las direcciones (de cuentas) dedicadas y administradas por código pueden ser creadas en la BC y accedidas por los contratos en la BSC, denominadas aquí "dirección de contrato en la BC" (Contract Address on BC - CAoB). 223 | 224 | Se implementan varias operaciones estándar: 225 | 226 | 1. Transferencia de BSC a BC: esto se implementa de la misma manera que una transferencia normal de BSC a BC, sólo que activada a través de un contrato estándar. El monto puede ser transferido a cualquier dirección en la BC, incluyendo la CAoB correspondiente del contrato de origen de la transferencia. 227 | 2. Transferencia en la BC: esto se implementa en la forma de una transferencia especial entrecruzada de cadenas, mientras que la transferencia real es desde una CAoB a cualquier otra dirección (inclusive otra CAoB). 228 | 3. Transferencia desde la BC a la BSC: esto se implementa como una comunicación de doble pasada entre cadenas cruzadas. La primera pasada se activa por el contrato BSC y se propaga en la BC, para que luego en la segunda pasada la BC comience una transferencia normal entrecruzada de cadenas desde la BC a la BSC, desde la CAoB a la dirección de contrato en la BSC. Se debe prestar particular atención al hecho de que el contrato BSC sólo incrementa el saldo a partir de cualquier transferencia entrante en la segunda pasada y el manejo de errores en dicha segunda pasada es el mismo tal como sucede en una transferencia normal desde la BC a la BSC. 229 | 4. Negociación IOC (Inmediatamente-o-cancelar): el principal objetivo de transferir activos a la BC es para su negociación. Este evento dará instrucciones para que negociando un cierto monto de un activo en la CAoB se obtenga a cambio otro activo tanto como sea posible y se transfieran los resultados, es decir el origen del que se parte y los tokens de destino producto de la negociación van de vuelta a la BSC. La BC gestionará tales eventos transmitidos enviando un "inmediamente-o-cancelar", es decir una orden IOC a los pares de la negociación, una vez que la coincidencia se cumple, el resultado será reenviado de vuelta a la BSC lo cual podrá ser o bien en uno o bien en otro de los activos negociados. 230 | 5. Transacción de subasta: tal evento instruirá a la BC para que envíe una orden de subasta para negociar un cierto monto de un activo en la CAoB con respecto a otro activo tanto cuanto sea posible y transferir de vuelta todos los resultados a la BSC al final de la subasta. La función de subasta está próxima a ser implementada en la BC 231 | 232 | Hay ciertos detalles respecto de la negociación: 233 | 234 | a. ambos pueden tener un precio límite (absoluto o relativo) para la negociación; 235 | 236 | b. el resultado final es escribirá como paquetes de cadenas entrecruzada para retransmitirlos a la BSC; 237 | 238 | c. es posible que se cobren tarifas de comunicación entre cadenas entrecruzadas respecto del activo transferido de vuelta a la BSC; 239 | 240 | d. El contrado BSC mantiene una copia en espejo del saldo y los pedidos pendientes en la CAoB. Más allá de cualquier error que pudiera ocurrir durante la transacción, el estado final se propagará de vuelta hacia el contrato de origen y hará efectivo su estado interno. 241 | 242 | Con las funcionalidades arriba presentadas, simplemente se agregan las funciones de transferencia e intercambio entrecruzado entre cadenas de bloques con alta liquidez en todos los contratos inteligentes en la BSC. En gran medida se agregarán los escenarios de aplicación en los contratos inteligentes y las dApps, para lograr 1 cadena + 1 cadena > 2 cadenas. 243 | 244 | # Staking y gobernanza 245 | 246 | La autoridad de la Prueba-de-participación (Proof-of-Stake) acarrea consigo la descentralización y el involucrarse de la comunidad. La esencia de su lógica puede resumirse como sigue: Pueden apreciarse ideas similares en otras redes, especialmente Cosmos y EOS. 247 | 248 | 1. Los tenedores de tokens, incluyendo a los validadores, pueden hacer que sus tokens estén "**vinculados**" a la participación (stake). Los tenedores de tokens pueden **delegar **sus tokens en cualquier validador o candidato a validador, con la expectativa que éste pueda convertirse realmente en validador; posteriormente pueden elegir un validador diferente o candidato en orden a redelegar sus tokens. 249 | 2. Todos los candidatos a ser validadores se ordenarán jerárquicamente según el número de tokens vinculados a ellos y los de más arriba se convertirán en los verdaderos validadores. 250 | 3. Los validadores pueden compartir (parte de) su recompensa por la producción de los bloques con sus delegadores. 251 | 4. Los validadores pueden sufrir un "**recorte**", es decir un castigo por mal comportamiento, como ser por realizar una doble firma y/o inestabilidad. Dicho castigo será compartido **asimismo por sus delegadores**. 252 | 5. Existe un "**período de desvinculación**" para validadores y delegadores de manera que el sistema garantice que los tokens permanezcan vinculados cuando un mal comportamiento es detectado; el responsable sufrirá un "recorte" durante este período. 253 | 254 | ## Haciendo staking en la BC 255 | 256 | Idealmente, dicha lógica de staking y recompensa debería estar integrada en la cadena de bloques y ejecutarse automáticamente en la medida en que se van formando los bloques. Cosmos Hub, el cual comparte la misma forma de consenso que Tendermint y las mismas librerías que BNB Beacon Chain, opera de esta forma. 257 | 258 | La BC ha sido preparada para habilitar la lógica de staking desde los primeros días de su diseño. Por otro lado, en cuanto la BSC quiere seguir siendo compatible con Ethereum tanto cuanto sea posible, esto conlleva un gran desafío a la vez que un gran esfuerzo para implementar dicha lógica en ella. Esto es así especialmente en cuanto que el mismo Ethereum podría modificar su forma de protocolo de consenso de Proof of Stake en un corto (o largo) plazo. En orden a mantener la compatibilidad y a reutilizar el beneficioso fundamento de la BC, la lógica de staking de la BSC se implementa en la BC: 259 | 260 | 1. El token para hacer stakin es BNB, en tanto constituye de todas maneras el token nativo de ambas cadenas de bloques. 261 | 2. El staking, es decir, tanto la vinculación de tokens como las acciones de delegación y registros de la BSC, tienen lugar en la BC. 262 | 3. El conjunto de validadores de la BSC está determinado por su lógica de staking y delegación, mediante un módulo de staking integrado a la BC que sirve a la BSC y que se propaga cada día a las 00:00 UTC desde la BC hacia la BSC mediante comunicación entrecruzada de cadenas. 263 | 4. La distribución de recompensas en la BC ocurre todos los días alrededor de las 00:00 UTC. 264 | 265 | ## Recompensas 266 | 267 | Tanto la actualización del validador como la distribución de recompensas ocurre cada día alrededor de las 00:00 UTC. Esto es así para ahorrar el costo de las frecuentes actualizaciones de staking y el costo que implica la distribución de recompensas por la formación de bloques. Estos costos pueden ser significativos en cuanto la recompensa por la formación de bloques se recopila en la BSC y se distribuye desde la BC hacia los validadores y delegadores de la BSC. (Notese que las costos derivados de la formación de bloques en la BC constituirán una recompensa sólo para los validadores de la BC.) 268 | 269 | Aquí se introduce deliberadamente un retardo para garantizar que la distribución sea justa: 270 | 271 | 1. La recompensa por formación de bloques no se enviará al validador de inmediato, sino que será calculada y acumulada en un contrato; 272 | 2. Al recibir la actualización del conjunto de validadores en la BSC, se activarán algunas transferencias entrecruzadas entre cadenas para transferir la recompensa a las direcciones de custodia en los validadores correspondientes. Las direcciones de custodia son propiedad del sistema por lo que la recompensa no puede ser gastada hasta que no se haga la distribución prometida a los delegadores. 1 Los inversores de BNB pueden proporcionar otros beneficios a los delegadores de BNB, tanto como lo hacen ahora con los tenedores a largo plazo de BNB. 273 | 3. En orden a simplificar la sincronización y a destinar tiempo para dar cabida a los recortes, la recompensa por T-días sólo se distribuirá en T-días+2. Luego que los delegadores obtengan la recompensa, el sobrante se transferirá a la dirección de recompensa propia de los validadores. 274 | 275 | ## Recortes 276 | 277 | El recorte es parte de la forma de gobernanza sobre cadena de bloques, para garantizar que los comportamientos negativos o maliciosos sean castigados. Un recorte en la BSC puede ser emitido por cualquiera. El envío de la transacción requiere **evidencia de recorte **y conlleva costos, pero también brinda una recompensa mayor cuando se cumple con éxito. 278 | 279 | Hasta el momento existen dos casos susceptibles de recortes. 280 | 281 | ### Doble firma 282 | 283 | Es una disfuncionalidad bastante grave y muy probablemente una ofensa deliberada cuando un validador firma más de un bloque con la misma altura y el mismo bloque matriz. La implementación del protocolo de referencia ya debería contar con la lógica para prevenir esto, de forma que sólo un código malicioso podría podría desencadenar este tipo de malfuncionamiento. Cuando ocurre un problema de doble firma, el validador debe ser eliminado inmediatamente del del **grupo **de validadores. 284 | 285 | Cualquiera puede hacer una solicitud de recorte en la BC con la evidencia de un problema de doble firmado en la BSC; evidencia que debe contener los dos encabezados de bloque con la misma altura y bloque principal, sellados por validadores infractor. Al recibir la evidencia, si la BC verifica su validez: 286 | 287 | 1. El validador será removido del grupo de validadores a través de una instancia de actualización del grupo de validadores y por una actualización entrecruzada de cadenas. 288 | 2. El staking del validador será recortado en un monto predefinido; 289 | 3. Parte del monto de BNB recortado será asignado a la dirección del remitente, lo cual constituye una recompensa mucho mayor que el costo de enviar la transacción de solicitud de recorte. 290 | 4. El resto del recorte de BNB se asignará a las direcciones de custodia de los otros validadores y distribuido entre todos los delegadores de la misma forma que la recompensa otorgada por la formación de bloques. 291 | 292 | ### Inestabilidad 293 | 294 | La vitalidad de la BSC se basa en el hecho que todos en el grupo de validadores de prueba de participación de autoridad pueden producir bloques a tiempo cuando es su turno. Los validadores pueden perder sus turnos por cualquier motivo, principalmente por problemas de hardware, de software, de configuración o por problemas en la red. Esta inestabilidad de la operación perjudicará el rendimiento de la red e introducirá un mayor grado de no-indeterminación en el sistema. 295 | 296 | Puede existir un contrato inteligente interno responsable de registrar las métricas perdidas de bloques de cada validador. Una vez que las métricas están por encima del umbral predefinido, la recompensa por la formación de bloques para el validador no será transmitida a la BC para su distribución, sino que será compartida con otros validadores mejores. De esta forma, el validador operacionalmente disfuncional deberá ser gradualmente eliminado del grupo de validadores mientras que sus delegadores recibirán menos o incluso ninguna recompensa. Si las métricas se mantienen por encima de otras con niveles por encima del umbral, el validador se eliminará de la rotación, lo cual se propagará de vuelta en la BC, donde tendrá lugar otro recorte en el staking del validador. 297 | 298 | ### Gobernanza de parámetros 299 | 300 | Existen muchos tipos de parámetros del sistema para controlar el comportamiento de la BSC como por ejemplo, el umbral de recorte y monto, los costos de transferencias cruzadas entre cadenas, etc. Todos estos parámetros serán determinados por el grupo de validadores de la BSC a través de un proceso de un voto-propuesta basado en el staking de aquellos. Tal proceso se llevará a cabo en la BC y los nuevos valores de los parámetros serán recogidos por el correspondiente sistema de contratos mediante una comunicación entrecruzadas entre cadenas. 301 | 302 | # Transmisores 303 | 304 | Los transmisores son los responsables de enviar paquetes de intercomunicación cruzada entre las dos cadenas de bloques. Debido a la estructura heterogénea de cadenas paralelas, se han creado dos tipos diferentes de transmisores. 305 | 306 | ## Transmisores de la BSC 307 | 308 | Los transmisores encargados de la comunicación entre la BC y la BSC se denominan "transmisores BSC" o simplemente "**transmisores**". La transmisión es un proceso independiente que puede ser ejecutado por cualquiera y en cualquier lugar, excepto por el hecho que los transmisores deben registrarse ellos mismo en la BSC y depositar una cierta cantidad reembolsable de BNB. La BSC sólo aceptará los solicitudes de transmisión de los transmisores registrados. 309 | 310 | El paquete que transmitan será verificado por el cliente ligero de la cadena en la BSC. Una transmisión exitosa requiere atravesar una verificación suficiente y los costos de las tarifas de gas en la BSC, y por lo tanto, tiene que haber incentivos de recompensa que alienten a la comunidad a ejecutar los transmisores. 311 | 312 | ### Incentivos 313 | 314 | Existen dos tipos principales de comunicación: 315 | 316 | 1. Operaciones de cliente, tales como vinculación cruzada entre cadenas, transferencia y gestión de errores, etc.: esto debe ser pagado por los que solicitan la transacción. 317 | 2. Sincronización del sistema, tales como el encabezado de cadena de bloques para verificación y la actualización del conjunto de validadores: lo cual contiene encabezados de bloques y cambios en el grupo de validadores, y debe pagarse por recompensa del sistema de la BSC. 318 | 319 | Si algunos transmisores poseen redes más rápidas y mejor hardware, podrían monopolizar todos los paquetes de transmisión y no dejar ninguna recompensa para los otros. Por lo que menos participantes se unirán para la transmisión, lo que fomenta la centralización y perjudica la eficiencia y seguridad de la red. Idealmente, debido a la descentralización y reelección dinámica de los validadores de la BSC, un transmisor difícilmente puede ser seimpre el primero en transmitir cada mensaje. Pero en orden a evitar aún más la monopolización, la economía de recompensas está también especialmente diseñada para minimizar tal posibilidad: 320 | 321 | 1. La recompensa para los transmisores sólo se distribuirá en lotes, y un lote cubrirá un número de paquetes transmitidos exitosamente. 322 | 2. La recompensa que puede obtener un transmisor por la distribuciónd de un lote no es linealmente proporcional al número de paquetes exitosamente transmitidos por él. En cambio, excepto los primeros pocos envíos, cuanto más transmita un transmisor durante el período de un lote, tanto menos recompensa obtendrá. Y el registro también aumentará el costo de dicho monopolio. 323 | 324 | ## Transmisores oráculo 325 | 326 | Los transmisores para la comunicación entre la BSC y la BC están utilizando el modelo de "oráculo", y el así llamado modelo "**oráculos transmisores**". Cada uno de los validadores debe ejecutar transmisores oráculos, y sólo pueden hacerlo aquellos que pertenecen al grupo de los validadores. Cada transmisor oráculo observa el cambio de estado de la BSC. Una vez que capta los paquetes de comunicación de cadenas entrecruzadas, someterá las solicitudes a votación. Luego que los transmisores oráculos, con más de ⅔ del poder de voto de los validadores de la BC, voten por los cambios, las acciones entrecruzadas de cadenas serán realizadas. 327 | 328 | Los transmisores oráculo deben esperar la cantidad suficiente de bloques para confirmar la finalización en la BSC antes de hacer el envío y emitir el voto por los paquetes de intercomunicación cruzada entre cadenas en al BC. 329 | 330 | Las tarifas de entrecruzamiento de cadenas será distribuida a los validadores de la BC junto con las recompensas normales devenidas de la formación de bloques en la BC. 331 | 332 | Este tipo de transmisión oracular depende del respaldo de todos los validadores. En tanto que todos los votos respecto de los paquetes de intercomunicación entre cadenas son registrados en la cadena de bloques, no es difícil tener un sistema métrico para evaluar el rendimiento de los transmisores oráculos. El peor actor podrá recuperar sus recompensas mediante otra lógica de recorte introducida en el futuro. 333 | 334 | # Perspectivas 335 | 336 | Es difícil arribar a una conclusión respecto de la BNB Beacon Chain ya que nunca ha dejado de evolucionar. La estrategia de una cadena dual consiste en abrir la puerta para que los usuarios aprovechen negociaciones y transferencias rápidas, por un lado, y por el otro, para permitir una programación flexible y extensible, pero esto constituirá tan sólo una parada a lo largo del desarrollo de la BNB Beacon Chain. A continuación de exponen los temas que se deben analizar en orden a facilitar la mejoría de la comunidad para una mayor usabilidad y extensibilidad: 337 | 338 | 1. Agregar modelos diferentes de activos digitales para diferentes casos de uso comercial. 339 | 2. Permitir una mayor comunicación de datos, especialmente datos de mercado DEX, para que puedan ser comunicados desde el BNB DEX a la BSC. 340 | 3. Proporcionar interfaz y compatibilidad para integrarse con Ethereum, incluyendo sus futuras actualizaciones, y con otras cadenas de bloques 341 | 4. Mejorar la experiencia del lado del cliente para administrar billeteras y para usar la cadena de bloques de una manera más conveniente. 342 | --------------------------------------------------------------------------------