chat.log

From François Garillot to Everyone 04:05 PM
There’s existing nomenclature on this
From Alberto Sonnino to Everyone 04:11 PM
Follower: Download/Read the state from one authority
Reconciliation: authorities chat with each other so they all catch up with the highest know state
From Sam Blackshear to Everyone 04:15 PM
Like that we’re compiling a glossary! One clarifying question: is reconciliation a process between two authorities, or can it involve N?
From Alberto Sonnino to Everyone 04:16 PM
Unclear until now
From ade to Everyone 04:17 PM
Run set reconciliation on Francois to update him on what we discussed
From Alberto Sonnino to Everyone 04:30 PM
My other big worry about protocol C is that light clients may be forced to use these state commitments for all their operations. And if they only happen every few min/sec, we may (in practice) increase our latency to the interval between state commitments. If that happens it does not matter that we run super low-latency FastPay.
From François Garillot to Everyone 04:32 PM
Protocol C is the only thing that affords serving reads from something else than authorities.
If we want to make sure that’s not the mainly used protocol it means that the authorities will have to serve most of the reads
From Evan Chan (he/him) to Everyone 04:33 PM
I’m afraid that without Protocol C, then anyone who wants the full state has to read from 2f+1 authorities, and read everything from all authorities.  I don’t see this as scalable and might be a huge DDOS risk.
From Sam Blackshear to Everyone 04:35 PM
> Protocol C is the only thing that affords serving reads from something else than authorities.

I think this is only true if you *must* have some notion of freshness of reads in addition to integrity. Certificates in isolation, with no state commitment, suffice for integrity, and provide a basis for bootstrapping the value of input objects (via read from an untrusted store + checking commitment in ObjectRef) and output objects (via local execution).
In many cases (e.g., sparse or full replay), you don't care about freshness, so I think this is an important distinction to make.
From Evan Chan (he/him) to Everyone 04:37 PM
I’d like to understand the “sparse or full replay you don’t need freshness”.   What is being referred to as freshness is what I’d call consistency in the CAP theorem.  If you don’t have consistency then how can you reliably process more data, unless you keep syncing more data from somewhere?
From Alberto Sonnino to Everyone 04:39 PM
(I am not saying we don’t need C, I am saying there is this added complexity to consider as well)
From Sam Blackshear to Everyone 04:44 PM
Evan (and we can also discuss separatel): to give a concrete example: say I'm an end-user on a phone trying to understand which objects I own.

- Because objects I own can only move via transactions signed by me, I don't need to be concerned at all about those objects going anywhere.
- The only thing I need to worry about is new objects others have sent me. I will learn about those via certificates, which I may get from a third party, an authority, or directly from the sender.
- Once I see a certificate, I trust it because it has the valid authority sigs, and the commitment to the input values lets me query a third party to learn the input values, and execute locally to learn the output values.

I think the subtlety here compared to CAP in an conventional system is that there is a notion of "state ownership" that we can leverage in many places--most state cannot change arbitrarily.
From Evan Chan (he/him) to Everyone 04:45 PM
Thanks Sam, what you’re saying is if I only care about my own certificates then it’s fine
From François Garillot to Everyone 04:48 PM
meeting later 😄
free 😄