FAQ About Tycho Hard Fork(Cancun on BSC)

BEP
,
1

Q1: What Is BSC Tycho hardfork

It is mainly to enable several Ethereum Cancun EIPs on BSC to keep EVM compatible and also the 4844 feature.
Here is the list of these EIPs.

Among these EIPs, 4844 is the most complicated and there would be some difference between BSC&Ethereum on implement 4844. But for other supported EIPs, they will be exactly the same as Ethereum.

Q2: Any Breaking Change

  • New data structure of block header/body
    If your project tries to encode/decode block header/body, make sure your project can support the new structure.
  • New transaction type: BlobTx, make sure your project can handle this type of transactions.
  • Several new EVM opcodes are introduced, make sure your project can handle it, especially when you have customized EVM implementation.
    The 4 new EVM opcodes: SLOAD(0x54), SSTORE(0x55 ), MCOPY(0x5E), BLOBBASEFEE(0x4a)
  • Large BlobTx, blob transaction can carry 6 blobs at most, which is 768KB(128*6), so transaction size could be much larger. Server may check network configuration like: nginx::client_max_body_size to allow large network packet.

Q3:FAQs About EIP-4844 On BSC

4844-Q1.Basic Parameters

Most of these parameters are same as Ethereum, for detail pls refer Design: EIP-4844 On BSC

  • Maximum Blobs Per Block: 6
  • Maximum Blobs Per Transaction: 6
  • Minimum BlobGasPrice: 1Wei
  • Blob Expiry: A blob remains available for exactly 524,288 (40963212/3sec) blocks, which is ~18.2 days, similar to Ethereum

4844-Q2.Difference Between BSC & Ethereum?

  • Propagation/Persistence Of Blobs: as there is no consensus layer on BSC, blobs will only be able to be saved and propagated by the execution layer. It is mainly the internal implementation difference, no big impact to users.
  • Blob Base Fee will be burnt on Ethereum, but not on BSC, as BSC already has its own burn Mechanism.
  • Query APIs: Ethereum provides Restful API on BeaconChain, while BSC will provide similar API on execution layer with RPC API.

4844-Q3: Reward Impact To Validators

The actual reward will depend on the real BSC rollup traffic after 4844 is enabled. Low rollup traffic would have limited impact to validators’ APY, while large rollup traffic with large blob gas price could greatly increase validators’ APY.
Let’s try to estimate the reward impact based on the validators’ recent APY and target blob traffic. Recently(Mar 2024), BSC validators would earn ~0.05 BNB per block, let’s calculate the APY impact based on it:

BlobPrice Blobs Reward(BNB) APY Increase
1 Gwei 3 ~0.0004(13128*1024/10^9) ~0.8%
3 Gwei 3 ~0.0012(33128*1024/10^9) ~2.4%
10 Gwei 3 ~0.004(103128*1024/10^9) ~8%
50 Gwei 3 ~0.02(103128*1024/10^9) ~40%
100 Gwei 3 ~0.04(103128*1024/10^9) ~80%
100 Gwei 6 ~0.08(103128*1024/10^9) ~160%

Overall, the real APY impact would largely depends on rollup traffic after 4844, the larger traffic volume and larger APY increase.

4844-Q4: How To Use 4844 On BSC?

Basically, the usage of blob transaction would be similar to Ethereum.

Optimistic rollups only need to provide the underlying data when fraud proofs are being submitted. The fraud proof can verify the transition in smaller steps, loading at most a few values of the blob at a time through calldata. For each value it would provide a KZG proof and use the point evaluation precompile to verify the value against the versioned hash that was submitted before, and then perform the fraud proof verification on that data as is done today.

ZK rollups would provide two commitments to their transaction or state delta data: the blob commitment (which the protocol ensures points to available data) and the ZK rollup’s own commitment using whatever proof system the rollup uses internally. They would use a proof of equivalence protocol, using the point evaluation precompile, to prove that the two commitments refer to the same data.

4844-Q5: Would Blob Size(0->6) Be Enough for BSC?

Take opBNB’s recent(2024-02-27) traffic for example, its average GasUsed per block is around 3.2M, it rollups ~117KB data to L1 every 15 seconds, equal to ~23.4KB for each block. For large traffic on opBNB, like 100M gas per block, it will be ~731KB(23.4*100/3.2), that is ~5.85 blobs(731KB/125KB).

So 6 blobs per block will be just enough to handle the maximum traffic of opBNB, if there are other L2s, then 6 blobs could be not enough. But at the first stage, we would prefer a conservative blob size, which will be the same as Ethereum, i.e. target 3 blobs and maximum 6 blobs for each block.

The blob size could be updated in the future.

4844-Q6: What If The Validator Hides The Blob?

Before 4844, the validator only needs to generate and broadcast the block. But after 4844, the block will generate blocks and blobs, what if the validator only broadcasts the block, not the blobs?
We make it mandatory for the validator to broadcast the blobs along with block, blocks without valid blobs would not be accepted by other peers and may be slashed.

4844-Q7: Storage Size For Blobs After 4844?

Similar to reward impact, storage increase would also depend on the real rollup traffic.
Each blob would be 128 KB, with 3 blobs per block and keep for ~18.2 days, the storage increase would be: (18.2 days * 24 hours * 3600 sec / 3 sec) * 3 * 128 KB ~= 192GB.

4844-Q8: Could BSC Include More Blobs Per Block?

Including more blobs will mainly cost extra network traffic load. Basically, BSC nodes are with higher HW specs than Ethereum, it might be able to include more blobs per block. But BSC also generate blocks more requently than Ethereum by 4 time, which means even with same blob size, BSC already has 4 times network traffic load. At the first stage, it would be better to be conservative, but it is possible to include more blobs in the future.

4844-Q9: About The Flag “–pruneancient”?

Many BSC nodes use this flag to only keep the most recent 90K blocks, which is ~3 days on BSC.
This flag would break the protocol, but it would still work and it needs to keep the recent 90K blocks’ blobs. For L2 users, it should avoid using this flag to run a BSC node, as blobs is critical for L2 users.

4844-Q10: The Expected Extra Network & IO Bandwidth?

It also depends on the real rollup traffic after 4844, let’s try to estimate, assume 3 blobs in a block.
Network Bandwidth

  • For mainnet cabinet validator, suppose it has 100 connected peers. It would be better to broadcast the block/blobs within 1 second to avoid trigger the in-turn/off-turn rule. So the network upload bandwidth needs: 3 * 128KB * 100 / 1s ~= 37.5MB/s, it could be a burden for validators, especially on consistent large rollup traffic. May need further optimization in the future.
  • For P2P nodes: suppose it has 1000 connected peers, as it only broadcast the content to sqrt of the peers, which would be ~32 peers, it also needs to make it down within 1 second, then the network bandwidth increase would be 12 MB, which could be much smaller than validators.

So validator node needs extra ~37.5MB network bandwidth, P2P node needs extra ~12MB network bandwidth.

Disk IO Bandwidth
It would be 3 * 128KB/3 = 128KB/s, so the extra disk IO pressure would be limitted.

4844-Q11: Block Header/Body Payload Change

The payload of BlockHeader and BlockBody will be changed after 4844, it mainly keeps the data structure same as Ethereum, but BSC does not ned withdrawal, so it will be empty but not nil.
The changes of Header and Body would be described as below:

Block Header

// Header represents a block header in the Ethereum blockchain.
type Header struct {
	ParentHash  common.Hash    `json:"parentHash"       gencodec:"required"`
	UncleHash   common.Hash    `json:"sha3Uncles"       gencodec:"required"`
	Coinbase    common.Address `json:"miner"`
	Root        common.Hash    `json:"stateRoot"        gencodec:"required"`
	TxHash      common.Hash    `json:"transactionsRoot" gencodec:"required"`
	ReceiptHash common.Hash    `json:"receiptsRoot"     gencodec:"required"`
	Bloom       Bloom          `json:"logsBloom"        gencodec:"required"`
	Difficulty  *big.Int       `json:"difficulty"       gencodec:"required"`
	Number      *big.Int       `json:"number"           gencodec:"required"`
	GasLimit    uint64         `json:"gasLimit"         gencodec:"required"`
	GasUsed     uint64         `json:"gasUsed"          gencodec:"required"`
	Time        uint64         `json:"timestamp"        gencodec:"required"`
	Extra       []byte         `json:"extraData"        gencodec:"required"`
	MixDigest   common.Hash    `json:"mixHash"`
	Nonce       BlockNonce     `json:"nonce"`

	// BaseFee was added by EIP-1559 and is ignored in legacy headers.
	BaseFee *big.Int `json:"baseFeePerGas" rlp:"optional"`

	// WithdrawalsHash was added by EIP-4895 and is ignored in legacy headers.
	WithdrawalsHash *common.Hash `json:"withdrawalsRoot" rlp:"optional"`

	// BlobGasUsed was added by EIP-4844 and is ignored in legacy headers.
	BlobGasUsed *uint64 `json:"blobGasUsed" rlp:"optional"`

	// ExcessBlobGas was added by EIP-4844 and is ignored in legacy headers.
	ExcessBlobGas *uint64 `json:"excessBlobGas" rlp:"optional"`

	// ParentBeaconRoot was added by EIP-4788 and is ignored in legacy headers.
	ParentBeaconRoot *common.Hash `json:"parentBeaconBlockRoot" rlp:"optional"`
}

image
image666×733 24.3 KB

Block Body

// BlockBody represents the data content of a single block.
type BlockBody struct {
	Transactions []*types.Transaction // Transactions contained within a block
	Uncles       []*types.Header      // Uncles contained within a block
	Withdrawals  []*types.Withdrawal  `rlp:"optional"` // Withdrawals contained within a block
	Sidecars     types.BlobSidecars   `rlp:"optional"` // Sidecars contained within a block
}

type BlobSidecar struct {
	BlobTxSidecar
	BlockNumber *big.Int    `json:"blockNumber"`
	BlockHash   common.Hash `json:"blockHash"`
	TxIndex     uint64      `json:"transactionIndex"`
	TxHash      common.Hash `json:"transactionHash"`
}

// BlobTxSidecar contains the blobs of a blob transaction.
type BlobTxSidecar struct {
	Blobs       []kzg4844.Blob       `json:"blobs"`       // Blobs needed by the blob pool
	Commitments []kzg4844.Commitment `json:"commitments"` // Commitments needed by the blob pool
	Proofs      []kzg4844.Proof      `json:"proofs"`      // Proofs needed by the blob pool
}

image
image1017×462 21.6 KB

4844-Q12: How To Get The Blobs

There are 2 new RPC API to get the blobs, check: Design: EIP-4844 On BSC

1 Like