Discussion topic for GitChain EIP:
2 Likes
Yes, ordering transactions by issue number ensures that transactions cannot be frontrun.
This also removes all security issues and operational challenges involved with validator key management, including support infrastructure such as the generic validator request bus, and the entire engine API interaction. There is no concept of INVALID payloads.
Wallets also no longer need to use a16z/helios to verify JSON-RPC responses. They can simply check the GitHub TLS signature and immediately know that the response is correct, immediately! No more 12s delay to wait for the sync committee signature, or 24s with ePBS, or 36s if state root computation is delayed… It’s all obsolete!
4444 is also included:
- For history, simply checkout the repository with a max
--depth - For state, use Git sparse checkout to only checkout the accounts that are of interest.
The response can be validated by checking the GitHub TLS signature. No Merkle proofs etc are needed, every subpage can be verified using TLS.
It is up to GitHub to switch to PQ signature schemes for TLS in time. Notably, it does not add complexity to the blockchain, it just continues to work as is.
Yes, this proposal does not require experimental zk crypto or crazy protocols. It is straight-forward to audit, based on established tooling.
EthPandaOps supports this EIP
1 Like
It’s a good point. GitHub is available globally, including regions that have more restrictive Internet access. GitChain is also auditable, the sequential indexing makes it obvious if a transaction suddenly disappears, as it leaves a gap in the issue numbering.
With the proposed timeline, do we have to propose it for inclusion in Fusaka? @timbeiko