protocol.texi (3667B)
1 @chapter Protocol 2 3 The @strong{usawa} project does not specify a strict protocol. 4 5 However, to guide the implementation to fulfill the design goals, some recommendations are given in the following. 6 7 8 @section Publishing and dissemination 9 10 All parties that wish to follow the ledger must be given clear rules on how to receive new entries. 11 12 There should be more than one channel through which entries are published, and ideally these "channels" should also include different platforms. 13 14 15 @subsection Dissemination example 16 17 All participants could be asked to follow both a @strong{nostr}@footnote{nostr is an ownerless, client- and server-agnostic protocol for publishing arbitrary content ("notes and other stuff"): @url{https://nostr.com/}} and an @emph{email mailist list}, that both would publish the full entry data as clearly defined data structures. 18 19 Also, all participants would be encouraged to follow an @emph{EVM chain}@footnote{A list of EVM chains: @url{https://chainlist.org/}} that could publish the latest ledger state digest in the data field of a transaction. 20 21 22 @section Authentication 23 24 In the @strong{usawa} system, signatures are not part of the immutable state. 25 26 Hence, once an entry is created, multiple parties may sign off on the transaction. 27 28 Authentication is contingent on the availability of the detached signatures. In other words, it is the responibility of each party wishing to verify the ledger to collect and store the signatures. 29 30 31 @subsection Procedure 32 33 To authenticate, signatures must be verified @emph{and} the signers must be trusted to make authentication statements. 34 35 In principle, a trusted signature on the last entry in a chain could be understood to be a statement of the entire entry chain. However, it is recommended that client software explicitly verifies trusted signatures on every entry. 36 37 38 @subsection Quorum 39 40 It is up to the client to determine the "weight" of signatures required to be considered authentic. 41 42 This weighting can be a number of principles, at discretion of the client: 43 44 * A single valid signature. 45 * `n` of out `m` signatures. 46 * Cumulative score of individually weighted signatures. 47 48 49 @subsection Local authentication 50 51 It is also recommended that the software adds the client's own signature over the entries. This way, entries can easily be authenticated in the future by merely checking for this signature. 52 53 In general, a local signature should always result in successful authentication (locally) of any data item, regardless of quorum. 54 55 56 @subsection Seal and deletion 57 58 As part of local authentication, entries should be explicitly sealed when considered authentic by the client. 59 60 To seal an entry means that the entry may no longer be deleted (or changed). It also means that any consecutive entry needs to have succeeding serial number to be successfully authenticated. 61 62 Any unsealed entry may be deleted, but doing so necessarily invalidates any succeeding entries using the digest of the deleted entry as its parent. 63 64 65 @subsection Example 66 67 Alice wants to know if a entry chain in a ledger is authentic. 68 69 Alice trusts any entry that has at least two signatures from either Bob, Carol or Dave. 70 71 Alice receives notification about a new entry. She inspects the entry. It has a signature from Carol. 72 73 Alice stores the entry, waiting for an additional signature. 74 75 Alice receives notification about a new signature. It has a signature from Dave on the same entry. Alice stores the signature. 76 77 Alice notices that the entry has quorum. Alice signs the entry. Alice stores her signature. 78 79 Alice seals the entry. 80 81 When Alices later views the ledger, each entry is authenticated against her signature.