search

onflow / flow-go

A fast, secure, and developer-friendly blockchain built to support the next generation of games, apps, and the digital assets that power them.
GNU Affero General Public License v3.0
534 stars 179 forks source link

New Trie Research #6558

Open j1010001 opened 1 month ago

j1010001 commented 1 month ago

Why (Objective)

Long-term: Execution state scalability (state proofs)

How will we measure success (Key Results) ?

6-month goal: Complete Architecture & Design so we can start implementation.

Effort Estimate

Time-box 40% of @fxamacker's capacity for this cycle for 2 days/week

DACI

Role Assigned
Driver @AlexHentschel
Approver @dete
Consulted @dete, @fxamacker, @ramtinms
Informed Flow Protocol engineering
bluesign commented 5 days ago

( Disclaimer: Noob comment, just trying to find out what I am missing here )

I commented on this long before somewhere, but couldn't find the comment yet. But basically it was something like this:

I checked a bit and current mtrie is pretty good actually, why research a new one ? I think PathFinder is the problem here;

if we had a PathFinder function F; something like accountIndex(owner) || [ ( slabId | ^specialRegisterIndex ) wouldn't it be enough ?

accountIndex is bound to 45 bits, if we reserve 64 bits for future. 192 bits for registers are more than enough. ( currently it is limited to 64 bits iirc )

this will compress the mtrie much better ( on accountIndex and slabId ) also it lets proofs to share most of the paths.