Economic Event Protocol for Distributed Ledgers
This is based on the Valueflows vocabulary, which defines the terms Economic Event and Agent.
An Economic Event is an event that affects an Economic Resource, like cut up some apples (consuming some resources, apples) and bake them into a pie (creating a new resource, an apple pie).
An Agent has agency and can perform Economic Events and reach agreements with other agents. An Agent could be a person or an organization.
This protocol is for Economic Events that involve more than one Agent, usually a Provider and a Receiver, and the two Agents are operating as different nodes in a distributed computing network with or without a shared database.
The goal of the protocol is to reach agreement between the provider and receiver on the Economic Event.
Reaching such an agreement might seem easy, but it can be difficult in a distributed computing environment. See https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
One of the components of this protocol will be a Distributed Ledger, and the interaction pattern is sometimes called Triple-Entry Accounting.
Triple-Entry Accounting is an idea mostly attributed to Ian Grigg: https://www.iang.org/papers/triple_entry.html
Distributed Ledgers are often implemented on blockchains, but this protocol will be technology-agnostic. The first implementations will be on Holochain and ActivityPub networks, which are really distributed, while blockchains are just multiple copies of the exact same data. (However, this protocol could also be implemented using a blockchain. It's agnostic.)
Likewise this protocol will differ in two ways from Ian Grigg's original proposal.
One difference is that Ian assumed a blockchain, while this proposal doesn't. The triple entries in Ian's proposal were one for each trading partner and a third on the blockchain as a distributed ledger.
The other difference is that Ian used double-entry accounting in one version of his proposal, so his trading partner entries had two entries each, making it really 5-entry accounting. This protocol assumes REA, which is an ontology for multi-agent accounting that records each entry once and only once from three different views: one for each trading partner, and the “independent view”, recorded on a distributed ledger. So it's like Ian's Single Entry version.
But REA is smart, so from the single entry, using its ontology, it can figure out all of the customary accounting reports as well as new analytical views of the data in the distributed ledger. See Accounting and Algorithms in the Valueflows documentation.
This paper REA, Triple-Entry Accounting and Blockchain: Converging Paths to Shared Ledger Systems explains the background and reasons for this protocol in greater detail. The description below summarizes the interaction steps in that paper.
Here's another shorter article about the same ideas:
Blockchain and eBusiness
The Protocol
Each Agent has its own private ledger, where each of them records their own views of the Economic Event.
The Provider signs and records the Economic Event in their private ledger, and sends the Economic Event record to the Receiver as well as to the Distributed Ledger.
The Receiving node signs and sends an acknowledgment that they got the Economic Event record. (This is just a communication acknowledgment, that the message was received by the Receiving Agent's network node.)
If the Provider does not get the Ack, they can resend, but that means the implementations need to use something like Mike Nottingham's POST Once Exactly (POE). Easiest way is probably unique message numbers on all messages and ignore duplicates coming in.
Then the Receiving Agent validates the Economic Event, and signs and sends either a valid or invalid message to the Provider as well as the Distributed Ledger.
Sometimes validation will require a human. For example, if the Economic Event reports a resource delivery, and the resource was not really delivered, or was the wrong resource, or damaged, or defective in some way, human judgment could be better than computation.
If valid, the Distributed Ledger signs the Economic Event record, which has now been committed, and this iteration of the protocol is finished.
If invalid, the two agents will need to engage in a conversation to either resolve the problem and send a validation message to the Distributed Ledger, or give up.
Distributed implementations
Holo-REA
Here's an overview from the developer, Pospi.
Using the Holochain “agent-centric” architecture, each Agent has their own Source Chain where they post their own views of the Economic Event. They also post the “independent view” of the Economic Event to the Holochain Distributed Hash Table (DHT), “A Public Distributed Database”.
The DHT is the shared Distributed Ledger. Pospi calls that “the community view”.
Bonfire
Bonfire is an implementation of ActivityPub (mentioned above with a link).
In that architecture, each Agent will have its own Inbox and Outbox. So the Provider will send the Economic Event record to the Inbox of the Receiver, and the Receiver will send their messages to the Inbox of the Provider.
The Distributed Ledger will be a Valueflows Scope, which will have its own ActivityPub Inbox and Outbox, and will save validated Economic Event and other economic records which reference the Scope. (If no Scope, no distributed ledger.)
One of the early use cases for the Bonfire Valueflows Distributed Ledger will be EveryCycle, a citizen-participation app for the Reflow project, creating circular economies in European cities.
