Modeling and Verification of Keeta's Consensus [pdf]

xescu.re

15 points·xescure··5 comments

Keeta developer here. I think the way we handle execution of code will be significantly different from Sui, both for stateful and stateless executions.

The man himself! Looking forward to it. I have a vague idea from your descriptions in the Keeta Discord, but it probably won’t fully click until I see it in use.

> Clients are responsible for managing conflicts and resubmitting transactions if necessary.

"Fat" clients need to talk to many "RPC"s at once and get final vote on "two phase" commit to their transaction.

Client is like Builder in Proposer builder separation.

Each representative stores all data for all accounts. They do DA.

Yep, clients are pretty heavy. There's actually a "publish aid" function where a proxy can contact the representatives for clients. I think these will be heavily used as more and more reps join and as clients get implemented in more constrained environments like mobile data.

Keeta is a new high-throughput payments blockchain. Its origins trace back to Nano, the feeless DAG DLT, and Facebook's FastPay, but it has plenty of novel contributions which warrant a formal look.

Here I present a formal Quint specification for its consensus protocol, model-checked under a Byzantine fault model. Safety was found to be preserved within the fault-bounds and under a constant weight model, and the possibility of FastPay style lockouts was reproduced as expected.

The direction for future research depends on the direction Keeta takes; checkpoints and epochs (similar to Sui) are the features to watch there.

Prerequisite paper: https://keeta.com/whitepaper.pdf

Google marketing slop: https://cloud.google.com/blog/topics/financial-services/how-...

Reply on news.ycombinator.com