Controller Blog Post #13
Conversation
|
There are still some TODOs (mostly diagrams to fill in and improve), but it could use some review to see if the story works as written. |
There was a problem hiding this comment.
Aside from my pedantic questions, I think the post is strong overall and flows in a similar cadence to the technical report. So it would be easy to read this then pick up the report.
I think if you have time or desire, its not strictly necessary that introducing interoperability and some of its limitations and best known methods could be a softer way to get into the post.
Most folks can't comprehend this type of world with resources flying all over the place yet. The links I sent in one comment should provide good motivation. I don't think its strictly necessary if you think it would detract from the content.
Also A high level tldr similar to what you have but bullet points would be helpful. Style/aesthetics is clearly your choice however.
| </figure> | ||
| TODO: better IFC-style wrapping/unwrapping diagram | ||
|
|
||
| The blockchain setting, however, introduces a unique twist: instead of relying on _trust_ as the main basis for endorsement, modern blockchains can have the power to _review_ and _verify_ histories of other chains, using [recursive ZKPs](https://eprint.iacr.org/2021/370), [optimistic proofs](https://www.coindesk.com/tech/2024/03/19/optimism-finally-starts-testing-fault-proofs-at-heart-of-design-and-of-criticism/), or simply fully replicating the other chain's state machine. |
There was a problem hiding this comment.
It might be helpful for the reader to name some examples, especially the recursive ZKP interoperability techniques;
- Agg Layer
- ZK IBC
or any others you know of. The reason it's important is that the industry is starting to realize that ZK will be crucial for interoperability going forward. As an example, my own naïveté
| We can encode extremely general mutable state with resources, but resources themselves are fairly simple. | ||
| Resources have very limited mutable state: they are _not yet created_ by default, can transition to _created_, and then to _consumed_. | ||
| However, each resource can carry arbitrary immutable data, specified by the resource's unique ID (which can be a hash). | ||
|
|
There was a problem hiding this comment.
A Resource can only have one controller, if I understand correctly. Maybe worth mentioning?
| Resources have very limited mutable state: they are _not yet created_ by default, can transition to _created_, and then to _consumed_. | ||
| However, each resource can carry arbitrary immutable data, specified by the resource's unique ID (which can be a hash). | ||
|
|
||
| Each controller's state carries cryptographic accumulators (e.g. [Merkle roots](https://doi.org/10.1007/3-540-48184-2_32)) representing the set of resources created by transactions ordered by this controller and the set of resources consumed. |
There was a problem hiding this comment.
By cryptographic accumulators, you are referring both to
| Crucially, resource logics can also constrain _where a resource can be transferred_: not all resources will be able to be transferred to all controllers. | ||
|
|
||
| ### Controller Tags | ||
| Each resource's _controller tag_ is part of this immutable data. |
There was a problem hiding this comment.
Is the controller tag information encoded in
- The creating controller
- The terminal controller
- A dependency graph (DAG) detailing which controllers may have corrupted the resource if they were Byzantine
| Each resource's tag therefore specifies a single controller that can order transactions for each type of transition, ensuring there is a single authority in charge of deciding whether each transition has or has not occurred: | ||
| - The resource's _creating controller_ determines if the resource has been created. | ||
| - The resource's _terminal controller_ determines if the resource has been consumed. | ||
| Transactions which perform a state transition but are ordered by the wrong controller are _invalid_. |
There was a problem hiding this comment.
what would be an example of this scenario?
- Controller B attempts to order Alice's resource
Cwhich belongs to Controller A?
| All state updates occur in [Transactions](https://en.wikipedia.org/wiki/Database_transaction): atomic updates that designate a set of _input_ resources (which must be previously _created_) that are _consumed_, and a set of _output_ resources (which must not yet have been created) which are _created_. | ||
| Transactions can only update state controlled by one controller, and must include checkable proofs that the relevant resource logics of each resource created or consumed are satisfied. | ||
| However, input resources may have been _created_ in a transaction on another controller. | ||
| Therefore, controllers can sync with one another, allowing transactions to check if resources on other controllers have been created. |
There was a problem hiding this comment.
can you elaborate on what this means?
therefore, controllers can sync with one another, allowing transactions to check if resources on other controllers have been created
|
|
||
|
|
||
| ### Controllers | ||
| Controllers order transactions: each controller decides on an ever-growing sequence of transactions defining the execution _trace_, and thus the current state, of a state machine. |
There was a problem hiding this comment.
going thought the report, thought this was the strongest one sentence definition of a controller. maybe worth elevating.
| ### Controllers | ||
| Controllers order transactions: each controller decides on an ever-growing sequence of transactions defining the execution _trace_, and thus the current state, of a state machine. | ||
| Controllers do not necessarily compute and store this state themselves, although it may be efficient to do so. | ||
| Committing to an ever-growing sequence of transactions, however, does require that controllers keep _some_ state, to ensure they do not _fork_: commit two contradictory traces (neither is a prefix of the other). |
There was a problem hiding this comment.
what happens when the commitment tree and nullifier set grow too large? pruned somehow?
There was a problem hiding this comment.
Great post, in general. I agree with @0xapriori's comments. I think readers would also really benefit from a big diagram which just portrays a bunch of controllers networked together, with different resources living on each one.
| We create a sound and efficient way to safely transfer arbitrary mutable digital objects (not just tokens) between mutually distrusting chains, tracking precisely how "trustworthy" each object is, and what "promises" each chain has made. | ||
| Our approach is based on [taint tracking](http://www.tcse.cn/~wsdou/papers/2022-dsn-dista.pdf) and _endorsement_ from [Information Flow Control](https://en.wikipedia.org/wiki/Information_flow_(information_theory)) research, with the added twist that modern blockchains can have the power to _review_ and _verify_ histories of other chains, using [recursive ZKPs](https://eprint.iacr.org/2021/370), [optimistic proofs](https://www.coindesk.com/tech/2024/03/19/optimism-finally-starts-testing-fault-proofs-at-heart-of-design-and-of-criticism/), or simply fully replicating the other chain's state machine. | ||
|
|
||
| TODO: actual ART-report link |
There was a problem hiding this comment.
This exists now - https://doi.org/10.5281/zenodo.10498997
There was a problem hiding this comment.
Or if you wanted the art.anoma.net link - https://art.anoma.net/list.html#paper-10498997
| In a distributed system, some controllers may be [Byzantine](https://en.wikipedia.org/wiki/Byzantine_fault), and make duplicitous or incoherent statements about state. | ||
| In general, an object is only as _trustworthy_ as its controller: if Alice's bank account says she has lots of money, but Bob doesn't trust Alice's bank, then Alice's "money" doesn't mean much to Bob. | ||
|
|
||
| In general, applications can only use objects on the same controller: ethereum transactions only use ethereum smart contracts and accounts, and so on. |
There was a problem hiding this comment.
style note: capitalize "Ethereum"
| However, each resource can carry arbitrary immutable data, specified by the resource's unique ID (which can be a hash). | ||
|
|
||
| Each controller's state carries cryptographic accumulators (e.g. [Merkle roots](https://doi.org/10.1007/3-540-48184-2_32)) representing the set of resources created by transactions ordered by this controller and the set of resources consumed. | ||
| If a resource is neither created nor consumed, it is _not yet created_. |
There was a problem hiding this comment.
(and, from the perspective of any query, not yet even existent)
Co-authored-by: Christopher Goes <[email protected]>
Co-authored-by: Christopher Goes <[email protected]>
Co-authored-by: Christopher Goes <[email protected]>
I wrote a blog post about controllers.