Minka Ledger is a microservice for currency-agnostic transaction processing using digital signatures.
Minka Ledger is a microservice for clearing transactions in multiple currencies using digital signatures. At its core, Minka Ledger is an implementation of the WebWallet API specification, and thus uses IOUs to represent transaction requests, authorize new transaction records and drive all state transitions using digital signatures. IOUs ("I owe you") are digitally signed messages that contain instructions for moving existing balances between accounts, getting new currency units into circulation or configuring parameters in order to implement different currency systems. The purpose of the Minka Ledger API is to verify and keep track of all incoming IOUs in real time in order to compute and serve three basic response types: account balances, transaction history and clearing confirmations.
IOUs are instructions for transferring currency units between accounts in a transaction.
Account balances represent the aggregate result of adding all incoming and subtracting all outgoing IOUs whose source or target is a specific account.
Minka Ledger uses a unified transactional model that supports arbitrary units of account (i.e. currencies) and allows any currency system to be implemented by simply configuring parameters.
In WebWallet, the "protocol" is the set of rules for transaction validation and clearing that describe how primitives are used as building blocks for assembling more expressive data structures, as well as the algorithms used to verify and modify the state of the system.
Primitives are building blocks for assembling more expressive data structures, such as transactions requests and records. Transactions are made of inputs and outputs, where inputs are usually IOUs, and outputs can be referenced by subsequent transaction pointers for spending.
Structures are combinations of primitives and are used to express collections of properties and the relationships between them. Transaction records are created by combining basic primitives into structures such as trees, graphs, blocks and stacks of blocks.
In order to modify the state of the system only through state transitions driven by digital signatures, as well as to verify the consistency all transaction records at any time using public-key cryptography, the protocol defines clearing, anchoring and validation algorithms for managing the ledger.
- Validation publicly verifiable data model
Minka uses URLs to define information spaces (Domains) in the Cloud.
A Domain, or an information space is a context in which information resources have location properties and direction relationships between them.
URLs are a useful convention for both naming and addressing in an information space. Besides the obvious benefits of Web compatibility, URLs are a way to emphasize the importance of logical decentralization and abstraction design so that Minka Cloud remains open to other implementation scenarios with different transport protocols and communication networks.
A Domain is usually represented as:
An example of a Domain in the Minka Cloud:
Domains can also be used to limit the development information space:
Signer the is an identifier for a collection of counters whose balances are controlled by the same cryptographic credentials. A counter is a data structure that contains properties of a numeric value, such as its unit of account and the constraints for modifying it. Signers are generated by encoding a cryptographic hash derived from one or more public keys. It is the public half of the private-public key.
A symbol (i.e. currency) is a namespace for uniquely identified counters whose numeric values are denominated in the same unit of account. Since any Signer can issue its own unit of account by signing IOUs denominated in its own identifier, Singers and Symbols identifiers look exactly the same, as shown by the examples above and below.
In the Wallet building block a Symbol can be assigned a handle for easier recognition such as $COP, $USD, $LUK.
An Action is a document that describes operations on counters based on references to previous results and instructions to modify their values. Transactions are identified by their cryptographic hashes, which are also represented as objects in order to make their properties explicit, such as the hash function. The example below shows another SHA-256 hash: