usawa

Signed, immutable accounting.
Info | Log | Files | Refs | Submodules | LICENSE

intro.texi (2867B)

      1 @chapter Overview
      2 
      3 The @strong{usawa} data format specification is an attempt at creating a portable, immutable and authenticated accounting schema.
      4 
      5 It is a @emph{decentralized ledger} project without being a @ref{blockchain_compare,blockchain}.
      6 
      7 At its heart, the specification is little more than a chained of entries, where each new entry points to the previous and is cryptographically signed.
      8 
      9 
     10 @section Design goals
     11 
     12 @itemize
     13 @item Enable publishing of ledger entries regardless of technology of platform.
     14 @item Primarily target an offline, local-first environment.
     15 @item Natively accommodate use of multiple currencies and units of accounts.
     16 @item Make receipts and other documentation aswell as conversion rates part of the immutable chain.
     17 @item Tailored for individuals and small businesses.
     18 @end itemize
     19 
     20 
     21 @anchor{blockchain_compare}
     22 @section Comparison with blockchain
     23 
     24 Although this specification may seem similar to a blockchain concept, there are some important differences. The difference can best be defined as what @strong{usawa} does @emph{not} seek to provide.
     25 
     26 
     27 @subsection No double-spend prevention
     28 
     29 The primary innovation of blockchains and the peer-to-peer software that support them is to solve the double-spend problem of decentralized transactions.
     30 
     31 @strong{usawa} is an @emph{accounting} project, and does not seek to solve such problems.
     32 
     33 
     34 @subsection No built-in finality and consensus.
     35 
     36 The @strong{usawa} specification only concentrates on @emph{how} to describe an accounting ledger and its evolving state.
     37 
     38 It leaves it up the implementer to create protocols and procedures to make sure that enough information of state is known to enough parties so that immutability can be enforced.
     39 
     40 
     41 @subsection No bundled dissemination.
     42 
     43 There is no node software specific to nor any protocol proposal for @strong{usawa} that defines how to make the state of the ledger known to all relevant parties at any one time.
     44 
     45 
     46 @section Cryptography
     47 
     48 Signatures and encryption use the @url{https://nacl.cr.yp.to/,NaCl} library. For the python implementation specifically, @url{https://pypi.org/project/PyNaCl/,PyNaCl} is used.
     49 
     50 The signature algorithm is the @strong{ed25519} implementation of the @url{eddsa,https://www.rfc-editor.org/rfc/rfc8032} recommendation.
     51 
     52 
     53 @section Development state.
     54 
     55 This is the documentation for version @code{0.1.0}.
     56 
     57 The software is currently considered to be in @emph{alpha state}.
     58 
     59 Breaking changes may be introduced on every minor version number increase.
     60 
     61 For each release (i.e. in git, a semver tag), the document @emph{should} cover the current state of the implementation.
     62 
     63 This documentation @emph{may} cover features not yet implemented. The @emph{inline code documentation} should be kept up to date before each merge to the @emph{master} branch. It should be consulted when in doubt about state of features.