Profile of BNBChainCore in Optimism

Posts by BNBChainCore

• Enable Custom Gas Token on OP Stack by BNBChainCore - No Role
  Posted on: March 19, 2024, 9:29 a.m.
  Content: 1 .Summary This proposal from BNB Chain Core Team to allows Layer 2 networks that build on OP Stack to define its own gas token independently, instead of being limited to Layer 1 ’s gas token. 2 .Abstract In the Ethereum Virtual Machine (EVM), a transaction call can be simply represented as a tuple {from, to, value, data, gaslimit}. OP Stack has implemented a seamless cross-chain transaction call between L 1 and L 2 layers: A transaction call happens on the source chain and will be fully executed on the target chain. Introducing the custom gas token will fundamentally change the meaning of the value field in the tuple: the different gas tokens on L 1 and L 2 mean that the value of gas tokens is no longer equal. By adjusting the token handling logic in the cross-chain communication layer(Portal and L 2 toL 1 MessagePasser), OP Stack can keep the semantic of cross-chain transaction calls the same, reducing the impact on other components. The fee of cross-chain transactions is influenced by custom gas tokens due to the different prices of gas tokens. By implementing a token price oracle and considering token prices for fee calculations, the system can still maintain financial balance even if the income and expenses are two distinct tokens. 3 .Motivation Many projects aspire to deploy their own layer 2 or even layer 3 solutions for various reasons: Low Transaction Fees: Scenarios like GameFi, SocialFi, and DEX platforms demand extremely cost-effective transaction fees. Customized Chain Requirements: Projects often require customized features and rapid iterations such as precompiled contracts, shorter block times, and customized Abstract Account solutions. They often want to enhance project value by issuing tokens that can serve as gas tokens on Layer 2 . However, OP Stack currently lacks support for this feature. Therefore, this draft focuses on enabling custom gas tokens on the OP Stack codebase. 4 .Specification 828 × 250 21 . 7 KB The current OP Stack’s cross-chain communication follows a layered model comprising application layer and communication layer. 4 . 1 Communication Layer The communication layer is accessible without permission. Developers can build their cross-chain applications on this communication layer, and native Token Bridge is one of the applications. The communication layer is primarily responsible for two key functions.： Implement cross chain transaction calls. This is achieved through the collaboration of Portal, MessagePasser contracts on two chains, along with op-node. The cross chain call can be represented as {from, to, mintValue, value, data, gaslimit}, the mintValue means the amount of minted L 2 gas token when deposit to L 2 , the value means the the transfer amount of L 2 gas token to the to account. Verification of Cross-Chain messages. In the process of L 1 to L 2 , the op-node observes the events on L 1 and includes deposit transactions into blocks, verification passes only if it can reach state consensus. The tx from L 2 to L 1 is verified through Merkel proofs and fraud proofs. The introduction of custom gas tokens mainly impacts the ‘value’ field in cross-chain transaction calls. To remove ambiguity about the “value” on both chains, we get two options here. 4 . 1 . 1 Option 1 : Enhance Cross Chain Transaction Call A cross-chain transaction call can be represented as：{from, to, mintValue, Value, remoteMintValue, remoteValue, data, gaslimit}. remoteMintValue and remoteValue refer to the amount of gas token on another chain in a cross-chain transaction. The Portal, MessagePasser and also the EVM need to adapt to this change to handle the remote tokens. For example, the depositTransaction of Portal need to charge the _remoteValue of custom gas token in ERC 20 format, the logic will be like: On the other hand, when the L 2 EVM handles the DepositTx, it will require to mint the L 1 gas token on L 2 in ERC 20 format and transfer to the target account. These happen during the EVM transaction pre-execution phase, not within smart contracts. 4 . 1 . 2 Option 2 : Wrap Cross Chain Transaction Call For L 1 to L 2 transaction calls, invoking Portal with msg.value is no longer allowed, a new parameter ‘mintValue’ will be introduced. The Portal needs to transfer the mintValue amount of L 2 custom gas token in ERC 20 format from msg.sender to itself. The previous opaqueData = abi.encodePacked(msg.value,_value,_gasLimit,_isCreation,_data) should be change to opaqueData = abi.encodePacked(‘mintValue’,_value,_gasLimit,_isCreation,_data) in the Portal contract. For L 2 to L 1 transaction calls, invoking L 2 toL 1 MessagePasser with msg.value is no longer allowed, a new parameter ‘callValue’ will be introduced. The L 2 toL 1 MessagePasser needs to transfer the callValue amount of L 1 gas token in ERC 20 format from msg.sender to itself. The WithdrawalTransaction in L 2 toL 1 MessagePasser will be changed from { nonce: messageNonce(), … value: msg.value…} to { nonce: messageNonce(), … value: callValue…} 4 . 1 . 3 Comparison Option 1 ’s framework is clearer but will require changes across multiple modules, including op-node and EVM. Option 2 is a simple and lightweight solution, however, its capability is slightly weaker than option 1 . Overall, the architecture of option 1 is better . 4 . 2 Application Layer The Messenger and Bridge modules together form the entire application, enabling tokens to flow freely between two chains. Messenger manages message nonces and failure retry mechanisms. Bridge acts as the gateway, providing user interfaces and managing token mapping relationships. The introduction of custom gas primarily impacts the Bridge module in two aspects: interfaces changed; Introduce two new interfaces depositGasToken and withdrawGasToken to reduce confusion, along with their corresponding finalize interface on the other chain. the processing logic of gas tokens on both chains changed. Because the gas token is an ERC 20 token on the other chain, this part should be properly handled. 4 . 3 L 1 to L 2 Fee When a user initiates a deposit transaction on Layer 1 and specifies a gas limit, this transaction will ensure that an equivalent amount of gas limit is executed or burned on Layer 1 as a form of fee charge. This mechanism serves to prevent DoS attacks on Layer 2 through cross-chain transactions. If L 2 adopts the custom gas token solution, there will be no need to charge fees by burning gas tokens on L 1 . When the gas limit exceeds a certain threshold, an amount of gaslimit * L 2 base fee of L 2 custom gas token will be transferred from the user’s account to a treasury account in ERC 20 format. In the ResourceConfig contract of L 1 , there are two parameters: minimumBaseFee and maximumBaseFee. By considering the prices of two gas tokens, setting these two parameters appropriately can make gaslimit * L 2 base fee approximately equal to the cost of executing this transaction on L 2 . The operator of L 2 subsequently has the authority to withdraw L 2 custom gas tokens from the treasury. 4 . 4 L 2 to L 1 Fee When users send transactions on L 2 , they are required to pay an L 1 Fee to cover the costs of DA and fixed overhead. The calculation formula for L 1 Fee is: L 1 Fee = L 1 GasUsed * L 1 GasPrice * FeeScalar. The L 1 GasUsed is related to the length of transaction raw data and compression rate. Considering the different prices of gas tokens on two chains, a new operator will be introduced: TokenPriceRatio. The formula will be: L 1 GasPrice = L 1 GasPrice * TokenPriceRatio L 1 Fee = L 1 GasUsed * L 1 GasPrice * FeeScalar However, the value of TokenPriceRatio cannot be automatically calculated by the system; it requires an Oracle mechanism where an off-chain service feeds the price into the L 2 contract. Price feeds come in different forms and algorithms, OP Stack can leave it to the maintainer of L 2 . Even if the price feed lags or is inaccurate, it won’t cause major financial losses, but may create an imbalance between income and expenses in a short period. 4 . 5 Wrap Gas Token Since the gas token is a wrapped ERC 20 token on another chain, the ERC 20 needs to be deployed in advance and maintained as globally unique. Typically, the gas token wrapped in L 1 already exists, so all that’s required is to pre-deploy the ERC 20 format contract of the L 1 gas token on L 2 . The issue of other L 2 tokens remains unchanged.
  Likes: 1 Replies: 0
  Likers: AxlVaz
  No replies yet.
• Enable Custom Gas Token on OP Stack by BNBChainCore - No Role
  Posted on: March 19, 2024, 5:29 a.m.
  Content: 1 .Summary This proposal from BNB Chain Core Team to allows Layer 2 networks that build on OP Stack to define its own gas token independently, instead of being limited to Layer 1 ’s gas token. 2 .Abstract In the Ethereum Virtual Machine (EVM), a transaction call can be simply represented as a tuple {from, to, value, data, gaslimit}. OP Stack has implemented a seamless cross-chain transaction call between L 1 and L 2 layers: A transaction call happens on the source chain and will be fully executed on the target chain. Introducing the custom gas token will fundamentally change the meaning of the value field in the tuple: the different gas tokens on L 1 and L 2 mean that the value of gas tokens is no longer equal. By adjusting the token handling logic in the cross-chain communication layer(Portal and L 2 toL 1 MessagePasser), OP Stack can keep the semantic of cross-chain transaction calls the same, reducing the impact on other components. The fee of cross-chain transactions is influenced by custom gas tokens due to the different prices of gas tokens. By implementing a token price oracle and considering token prices for fee calculations, the system can still maintain financial balance even if the income and expenses are two distinct tokens. 3 .Motivation Many projects aspire to deploy their own layer 2 or even layer 3 solutions for various reasons: Low Transaction Fees: Scenarios like GameFi, SocialFi, and DEX platforms demand extremely cost-effective transaction fees. Customized Chain Requirements: Projects often require customized features and rapid iterations such as precompiled contracts, shorter block times, and customized Abstract Account solutions. They often want to enhance project value by issuing tokens that can serve as gas tokens on Layer 2 . However, OP Stack currently lacks support for this feature. Therefore, this draft focuses on enabling custom gas tokens on the OP Stack codebase. 4 .Specification 828 × 250 21 . 7 KB The current OP Stack’s cross-chain communication follows a layered model comprising application layer and communication layer. 4 . 1 Communication Layer The communication layer is accessible without permission. Developers can build their cross-chain applications on this communication layer, and native Token Bridge is one of the applications. The communication layer is primarily responsible for two key functions.： Implement cross chain transaction calls. This is achieved through the collaboration of Portal, MessagePasser contracts on two chains, along with op-node. The cross chain call can be represented as {from, to, mintValue, value, data, gaslimit}, the mintValue means the amount of minted L 2 gas token when deposit to L 2 , the value means the the transfer amount of L 2 gas token to the to account. Verification of Cross-Chain messages. In the process of L 1 to L 2 , the op-node observes the events on L 1 and includes deposit transactions into blocks, verification passes only if it can reach state consensus. The tx from L 2 to L 1 is verified through Merkel proofs and fraud proofs. The introduction of custom gas tokens mainly impacts the ‘value’ field in cross-chain transaction calls. To remove ambiguity about the “value” on both chains, we get two options here. 4 . 1 . 1 Option 1 : Enhance Cross Chain Transaction Call A cross-chain transaction call can be represented as：{from, to, mintValue, Value, remoteMintValue, remoteValue, data, gaslimit}. remoteMintValue and remoteValue refer to the amount of gas token on another chain in a cross-chain transaction. The Portal, MessagePasser and also the EVM need to adapt to this change to handle the remote tokens. For example, the depositTransaction of Portal need to charge the _remoteValue of custom gas token in ERC 20 format, the logic will be like: On the other hand, when the L 2 EVM handles the DepositTx, it will require to mint the L 1 gas token on L 2 in ERC 20 format and transfer to the target account. These happen during the EVM transaction pre-execution phase, not within smart contracts. 4 . 1 . 2 Option 2 : Wrap Cross Chain Transaction Call For L 1 to L 2 transaction calls, invoking Portal with msg.value is no longer allowed, a new parameter ‘mintValue’ will be introduced. The Portal needs to transfer the mintValue amount of L 2 custom gas token in ERC 20 format from msg.sender to itself. The previous opaqueData = abi.encodePacked(msg.value,_value,_gasLimit,_isCreation,_data) should be change to opaqueData = abi.encodePacked(‘mintValue’,_value,_gasLimit,_isCreation,_data) in the Portal contract. For L 2 to L 1 transaction calls, invoking L 2 toL 1 MessagePasser with msg.value is no longer allowed, a new parameter ‘callValue’ will be introduced. The L 2 toL 1 MessagePasser needs to transfer the callValue amount of L 1 gas token in ERC 20 format from msg.sender to itself. The WithdrawalTransaction in L 2 toL 1 MessagePasser will be changed from { nonce: messageNonce(), … value: msg.value…} to { nonce: messageNonce(), … value: callValue…} 4 . 1 . 3 Comparison Option 1 ’s framework is clearer but will require changes across multiple modules, including op-node and EVM. Option 2 is a simple and lightweight solution, however, its capability is slightly weaker than option 1 . Overall, the architecture of option 1 is better . 4 . 2 Application Layer The Messenger and Bridge modules together form the entire application, enabling tokens to flow freely between two chains. Messenger manages message nonces and failure retry mechanisms. Bridge acts as the gateway, providing user interfaces and managing token mapping relationships. The introduction of custom gas primarily impacts the Bridge module in two aspects: interfaces changed; Introduce two new interfaces depositGasToken and withdrawGasToken to reduce confusion, along with their corresponding finalize interface on the other chain. the processing logic of gas tokens on both chains changed. Because the gas token is an ERC 20 token on the other chain, this part should be properly handled. 4 . 3 L 1 to L 2 Fee When a user initiates a deposit transaction on Layer 1 and specifies a gas limit, this transaction will ensure that an equivalent amount of gas limit is executed or burned on Layer 1 as a form of fee charge. This mechanism serves to prevent DoS attacks on Layer 2 through cross-chain transactions. If L 2 adopts the custom gas token solution, there will be no need to charge fees by burning gas tokens on L 1 . When the gas limit exceeds a certain threshold, an amount of gaslimit * L 2 base fee of L 2 custom gas token will be transferred from the user’s account to a treasury account in ERC 20 format. In the ResourceConfig contract of L 1 , there are two parameters: minimumBaseFee and maximumBaseFee. By considering the prices of two gas tokens, setting these two parameters appropriately can make gaslimit * L 2 base fee approximately equal to the cost of executing this transaction on L 2 . The operator of L 2 subsequently has the authority to withdraw L 2 custom gas tokens from the treasury. 4 . 4 L 2 to L 1 Fee When users send transactions on L 2 , they are required to pay an L 1 Fee to cover the costs of DA and fixed overhead. The calculation formula for L 1 Fee is: L 1 Fee = L 1 GasUsed * L 1 GasPrice * FeeScalar. The L 1 GasUsed is related to the length of transaction raw data and compression rate. Considering the different prices of gas tokens on two chains, a new operator will be introduced: TokenPriceRatio. The formula will be: L 1 GasPrice = L 1 GasPrice * TokenPriceRatio L 1 Fee = L 1 GasUsed * L 1 GasPrice * FeeScalar However, the value of TokenPriceRatio cannot be automatically calculated by the system; it requires an Oracle mechanism where an off-chain service feeds the price into the L 2 contract. Price feeds come in different forms and algorithms, OP Stack can leave it to the maintainer of L 2 . Even if the price feed lags or is inaccurate, it won’t cause major financial losses, but may create an imbalance between income and expenses in a short period. 4 . 5 Wrap Gas Token Since the gas token is a wrapped ERC 20 token on another chain, the ERC 20 needs to be deployed in advance and maintained as globally unique. Typically, the gas token wrapped in L 1 already exists, so all that’s required is to pre-deploy the ERC 20 format contract of the L 1 gas token on L 2 . The issue of other L 2 tokens remains unchanged.
  Likes: 4 Replies: 1
  Likers: AxlVaz, crypfuto, misa198, TomaszW
  Replies:

  • Rods2000: BNBChainCore: The communication layer is primarily responsible for two key functions.： Wouldn’t this further complicate the existing proposal allowing users to switch their L1 Gas token from ETH to OP? and or should this possibly beneficial option be considered once the core ETH/OP gas token topic is decided upon?