Protocol version 0.5: The Protocol Evolution Update

[lyulka]

This is the central list of changes and improvements that we plan to make for protocol version 0.5.

Version 0.5 has two high-level aims:

1. Rectify the idiosyncrasies of protocol version 0.4.
2. Set the stage for smoother protocol upgrades in the future.

Changelog

ParallelChain Protocol v0.5 changelog (HackMD)

Project management

GitHub Project

[lyulka]

I made changes to the changelog to be clear that we are going to use “V1, V2, V3…” to version individual components instead of naming versions of components according to the protocol version they are introduced in (i.e., “V04, V05, …”).

Previously, I had referred to the old version of P2P as P2P v0.4, and the new version of P2P as P2P v0.5.

This change makes things more consistent, and by decoupling the versioning of individual components from the versioning of the protocol as a whole, will reduce confusion in the future. (For example, if we do not make any changes to “P2P v0.5” for a long time, it could be that the protocol as a whole is already at v3.0 or whatever while P2P is still marked as “v0.5”, which is confusing).

@AlvinHon

[lyulka]

I removed the changes to num_proposed_block from the changelog.

We’ll add the fix for num_proposed_block in a future protocol version after we’ve resolved parallelchain-io/hotstuff_rs#17.

[lyulka]

I added a target block time, version upgrade section to the changelog, which specifies how Pacemakers should update their minimum_view_timeout to allow for enough time to produce and validate the block containing the version upgrade Next Epoch command.

A concrete way to implement this in the integration of HotStuff-rs v0.3 into Fullnode is to create a new Pacemaker that is the same as DefaultPacemaker, but holds the receiving side of an mpsc::sync_channel that informs it when a block with height $B{height, nv0.5} - 2$ is committed, and again when a block with height $B{height, nv0.5}$ is committed.

@TLiu2084 @karolinagrzeszkiewicz.

[lyulka]

I filled in the new minimal size of command receipts and receipts, as well as transaction inclusion cost in the changelog. Please verify whether these are correct and matches what you’ve implemented in Runtime v0.5.

@cy6581 @AlvinHon

[cy6581]

I filled in the new minimal size of command receipts and receipts, as well as transaction inclusion cost in the changelog. Please verify whether these are correct and matches what you’ve implemented in Runtime v0.5.

@cy6581 @AlvinHon

Thanks @lyulka I verified that the calculations tally with the structures of CommandReceiptV2 and ReceiptV2. Will ensure they are used accordingly.

[lyulka]

Summary of World State design meeting (17 Nov 2023)

1. We identified that the Trie Layout we are planning to move to in World State V2 has the limitation that "logical keys" cannot be longer than 64 bytes.
2. We discussed options to work with this limitation, and we agreed that Keccak256-hashing "user-provided" keys before handing them to trie_db is the best option.
3. We discussed possible consequences of making this change: it will make it more difficult for us to "enumerate" through all key-value pairs in any subset of trie.
4. We reached the tentative conclusion that:
   • We currently do not need this functionality (enumerating through keys).
   • If we need this functionality in the future, there are ways we can add it (by building a reverse index from hashes -> logical keys).
5. We agreed to do more analysis about the rationale in Ethereum and other systems for hashing logical keys before inserting them (DDoS protection).
6. @lyulka will update the protocol v0.5 changelog to reflect this change.

[lyulka]

@ZUOYANGDING @cy6581, I've updated the changelog to reflect the fact that MPT V2 is going to Keccak256 hash keys longer than 32 bytes before passing them to trie_db. The changes are in the "World State" and "Gas" sections of the changelog.

When making the changes to the Gas section, I realized that the current presentation of the section (as published in v0.4 of the protocol) makes it quite awkward to present the changes. Therefore, I created a new presentation for the changelog and then completed a substantial refactor of the world state storage and access section of the v0.4 protocol specification to match the changelog's presentation. This is a refactor, so the observable behavior of protocol v0.4 implementations should remain the same.

@cy6581, please read and see if I made any errors in the refactor, or if any parts are unclear (it may take one some time to understand the changes).

[lyulka]

@cy6581 I made a further update to the changelog to include the cost of Keccak256-hashing keys longer than 32 bytes in the cost formula for MPT get. Since the cost formula for MPT set includes the cost formula for MPT get as a term, this change is reflected in that formula as well.

[lyulka]

Summary of world state access gas costs design meeting (23 Nov 2023)

1. We agreed to not hash Accounts Trie keys. Only Storage Trie keys with length equal to or greater than 32 bytes will be hashed.
2. We agreed to retain the “simulated architecture” assumed in protocol v0.4 where Storage Tries are “attached” to the Accounts Trie.

Alice will update the changelog to reflect these decisions.

[lyulka]

@cy6581 the World State access section has been updated to reflect the decisions we made in yesterday's design meeting.

[lyulka]

@AlvinHon, I fixed the mistake you spotted in the changelog regarding $B{basefeedelta, v2}$. The “minimum -1” adjustment that we make when $pgu$ is less than $B{targetgasused}$ has been removed.

Additionally, the specification of $B_{basefeedelta}$ in protocol v0.4 has been fixed as well to reflect how we make different (minimum -1 vs. maximum +1) adjustment when $pgu$ is less than target gas used or greater than target gas used.

[lyulka]

@TLiu2084 @AlvinHon, I added a new variant to SubmitTransactionErrorV2 called TransactionVersionTooOld. This variant is returned when a client tries to submit a TransactionV1 to a Fullnode that no longer accepts V1 transactions.

[lyulka]

@TLiu2084 I've updated subscribe_to_transaction_events to use the HTTP "GET" method, as well as carry its parameters as a query string.

[lyulka]

@TLiu2084 @cy6581 @ZUOYANGDING, I've updated the following sections of the changelog:

1. The MPT section has been removed. MPTs will continue using NoExtensionLayout (this was the only changed previously planned to MPTs, so removing this means removing the entire section of the changelog).
2. The Storage Trie section has been updated. It no longer specifies that keys longer than or equal to 32 bytes have to be hashed before inserting them into a backing MPT.
3. A new RPC has been added: state/v2.

Tomorrow, I will update the Storage Trie operations gas formulas to reflect the fact that we no longer plan to start hashing keys longer than or equal to 32 bytes.

Please comment if there are any issues or omissions in my edits.

[lyulka]

@cy6581 I updated the World State access gas costs section to reflect the fact that we no longer plan to start hashing keys longer than or equal to 32 bytes.

[lyulka]

@TLiu2084 I updated the subscribe_to_transaction_events RPC to remove the requirement that Base64URL encoded query parameters need to be wrapped by double quotes (to make parsing easier).

[lyulka]

@cy6581 one thing that the protocol v0.5 changelog currently does not specify is whether, for non-call commands, refunds should offset the entire transaction, or only offset a single command. This may have become more relevant since we've split up the gas_used field across multiple command receipts with this release.

Let's discuss what the desired behavior should be later.

[lyulka]

@AlvinHon I changed the Kademlia protocol name of P2P V2 from "parallelchain_mainnet/v0.5" to "parallelchain_mainnet/v2".

[lyulka]

@AlvinHon, I updated the specification of transaction events in the changelog to give more detailed guidance about what scenarios each event and reason variant corresponds to.