Aragon Nest Proposal: Optimistic UI for Blockchain Interfaces (Gnarly)

[mykelp]

Aragon Nest Proposal: Optimistic UI for Blockchain Interfaces (Gnarly)

Authored with @shrugs

Abstract

Severe Asynchronicity is the experience of using a first-layer blockchain today:

• transactions publish within a reasonable timeframe (ms) but at very low confidence—it’s hard to know if and when they will succeed
• transactions are finalized within an unreasonable timeframe (minutes/hours) but with very high confidence
• Off-chain state is uncertain due to [1], [2], block re-orgs, short-lived forks, uncles, etc,
• Off-chain software isn’t perfect; it can lag behind the blockchain (if waiting for confirmation blocks), fail to replay state updates in the event of reorgs/forks, improperly handle unconfirmed transactions, and much, much more.

Users have no insight into what’s happening to a transaction and how their future actions are
affected—and if they do have insight, it’s within an unfriendly loading screen that doesn’t indicate
the confidence that a transaction will succeed. Waiting on transactions is a huge sticking point for
the user experience. I can’t move forward and perform other tasks if I’m not confident that the first
thing I did will succeed. Giving the user confidence in their actions is necessary, especially for
high-performance applications and games.

Gnarly reduces blockchain events into a steady state with confidence.

• Enables declarative, reactive clients
• The optimistic ui pattern applies expected changes with instant updates, but reverts to source of truth as soon as it’s known. This reduces blockchain events into a steady state with the client only knowing what the state is right this second with appropriate confidence in order to do its business,
• Reducing blockchain events to a steady state optimizes client queries and allows interfaces to design better data stores
• Graceful block reorganization and invalid state handling
• Friendly error management means (i) developers get reasonable error contexts and (ii) consumers get explanations about errors
• Friendly error management allows anyone to know (i) that something occurred and (ii) why it occurred and (iii) how it affects their actions,
  supports replay from arbitrary blocks to (i) bootstrap the steady state and (ii) resume after failures,
  default output is catered towards a graphql consuming client

Deliverables

A library/framework that implements this design, and can be run in both server and client environments. It persists data to traditional stores e.g. couchdb/pouchdb. Has to handle short lived forks, uncles, block reorganizations and time traveling.

Grant size

TBD

Application requirements

• Experience building consumer facing blockchain products to demonstrate understanding of the problem
• Expert level web development experience, with a history in reactive programming environments
• Details of the team members, alongside with their willingness in terms of implication
• Estimated average burn rate for completing the deliverables

Development timeline

Estimated 1 - 2 months

[izqui]

Please @mariapao expedite review

[mariapao]

Hi @mykelp your proposal is approved! We can't wait to have fuckin' Gnarly (using Matt's words;)). The next step is for you guys to submit your application following these instructions. Feel free to ask as many questions you have about the process!

[mariapao]

I'm closing this proposal as it is no longer a priority for the Aragon project