hashblock / hashblock-exchange

Sawtooth transaction families for an event accounting distributed ledger application

Hashblock Exchange

Hashblock Exchange enables encrypted data in flight and at rest while also providing exchange transaction anonymity.

Note: hashblock-exchange is alpha only and not considered production ready.

No Batteries Required

Refer to the Quick Start document to get up and running with hashblock-exchange.

Hashblock Exchange Back Story

First generation blockchain applications use UTXO transactions to record the value of a single resource that is minted and transferred between blockchain addresses. Bitcoin is an example of a first generation blockchain.

Second generation blockchain applications use single-resource smart-contracts to record the value of a resource that is minted and transferred between blockchain addresses. The ICO (initial coin offering) smart contract is an example of a second generation blockchain application.

Third generation blockchains use multi-resource smart-contracts to record the multi-dimensional and multi-scale values of multiple resources that are minted and exchanged between blockchain addresses. The hashblock-exchange setting, asset, and match family of smart contracts are an example of a third generation blockchain application.

The limitations of transfer-of-value smart contracts are exemplified by the fact that cryptocurrency brokerages do not use a blockchain to record the exchange of value when fiat currency is exchanged for cryptocurrency or visa-versa. A blockchain is used to record the transfer of value when units of a single resource are transferred between accounts. The cash receipt you get from a cash register is an example of a multi-resource value exchange because the receipt registers the quantity or product and the quantity of cash that is exchanged between two parties.

Hashblock Exchange Current State

hashblock-exchange overcomes these limitation with multiple smart contract transaction families.

• The setting transaction family is used to set/update the authorization contraints for asset and unit proposals and voting.
• The asset transaction family is used to propose and vote on general asset entities on the chain. These assets are referenced in the match transactions.
• The unit transaction family is used to propose and vote on units-of-measure entities on the chain. These assets are referenced in the match transactions and will be of further use in exchange conversions.
• The exchange transaction family uses Unmatched Transaction Quantity (UTXQ) and Matched Transaction Quantity (MTXQ) transactions to record the dual initiating and reciprocating events that comprise a value exchange. An exchange could be potential as in an ask/tell duality, or contractual as in an offer/accept duality, or operational as in a commitment/obligation duality, or actual as in a give/take duality. The match transaction family also validates that initiating events are not double matched and that the value of exchange assets balances. In contrast to a value-transfer balancing equation, input-value=output-value, a value-exchange balancing equation requires a ratio, unmatched-quantity * ratio = matched-quantity. Hashblock uses a Godel Hash encoding of units-of-measure and resources so that balancing equations like 5.bags{peanuts} * $2{USD}/1.bag{peanuts} = $10{USD} can be validated algebraically.

Designing hashblock-exchange smart contract validation rules as algebraic expressions simplifies the application of zkSNARK cryptology to the problem of having to expose transaction data to blockchain node validators so that they can validate the accuracy of a transaction. zkSNARK makes it possible to hide transaction data in a non-interactive argument of proof so that blockchain node validators can verify, with a high degree of probability, that balancing equations are satisfied without having to know the magnitudes, units, and resources, of the quantities in the equation. The zkSNARK wiki page shows how a balancing equation is converted into a rank-1 constraint system that can be used with the libsnark library to generate non-interactive proofs of knowledge off-chain, and to verify proofs of knowledge on-chain. Hashblock-exchange alpha uses a Elliptic Curve Diffie-Hellman algorithm to encrypt and decrypt balancing equation quantities to keep data on the blockchain private to node verifiers, and public to off-chain applications.

hashblock-exchange's Issues

Refactor 'sawtooth_units' to 'hashblock_units'

To align with our namespace:

• Namespace changes, code and unit test changes.
• Update build_all, run_tests

Update Wiki pages for 0.1.0 refactoring

Cosmetic changes to terminologies, etc.

UOM Vocabulary

Define the data model and vocabulary (verbs) for UOM transactions.

Implement unit test framework for uom

Now that we have a runnable TP we can add in the testing framework to progress in earnest with quality

Test transactions from afar

Use church key

Add balancing equation to reciprocte event validation

IE.Quanity * RE.Ratio = RE.Quantity

This equation must balance for quantity values and for each element of the multi-dimensional unit vector.

hashblock ledger

Run-At

Frank needs to set up a visual debugger

Logging is not very efficient. Take the time .....

Convert 'sawtooth-units' to 'hashblock-units' as well as other mentions

Untether unit signature and authorization keys (units, events) generation and registration from validator

Using REST-API or other...

Change units address prefix

For example:

hashlib.sha512('units'.encode("utf-8")).hexdigest()[0:6]

Refactor UOMProposal proto

settings should be named unit

Leverage Docker Hub build for production repo images

Connects directly to source push events to trigger the builds

For events, consider using the transaction header in TP to get state key

The intent of the inputs/outputs, see Here is to provide a list of addresses that identify to the context manager what address a transaction is authorized to read (inputs) and write (outputs) state.

Issue that comes to mind is that the inputs/outputs of transaction block may contain more than one entry. If this case is true then we would not know which one is the address to use in state management

Pull request for validator STL-1125

Set up network nodes

FC Create autonomous transaction families by extending build_all to create images. - COMPLETE
FC Push images to docker hub - COMPLETE
FC Update yaml file to pull production sawtooth and the latest hashblock images - UPDATED
FC Create Shell autonomous image - COMPLETE

AG Create hashblock organization in Docker Hub - COMPLETE
AG Enable automatic builds from Docker Hub via Github pushes
AG Deploy images
AG Configure peer nodes
AG Test transactions

Encrypt and decrypt all data on the chain

The value, and units hashes that are used by the balancing equation to validate a transaction needs to be encrypted so that transactions are secret. The public keys used to identify trading parties should also be anonymized.

units-dev exits immediately

Log snippet

Attaching to units-dev, sawtooth-validator-local, units-processor, sawtooth-rest-api-local
sawtooth-validator-local | writing file: /etc/sawtooth/keys/validator.priv
sawtooth-validator-local | writing file: /etc/sawtooth/keys/validator.pub
sawtooth-validator-local | Generating /var/lib/sawtooth/genesis.batch
units-dev exited with code 0

Validate no double matching

Just like you have to check for no double spending in UTXO ledgers you need to check for no double matching in event chain ledgers. It is possible for a block to contain two receipt events that both match to the same initiate event. This is not allowed and should be validated.

Overhall protobufs to use 'unit' instead of 'uom'

Big change effects handler.py and unit tests.

cli is defaulting to "localhost:8008" but that is not defined in container.

When CLI is running it is doing so with the sawtooth-rest-api container. Accessing the rest API should direct to: http://rest-api:8008 as that is how it is mapped.

Expand transaction vocabulary

We need to add ask/tell, offer/accept, commitment/obligation, give/take vocabulary so that matching can be 2,3, and 4 way.

Support running eventsset from hashblock-shell container

Reduce littering of sawtooth-validator container

Secure the network

Listings from `eventsset` should include listing of reciprocated initiate events as well as reciprocate events and/or the relationship between the two

UOM Docker images and composers

Setup both which support running, building and testing

Is this the puppy?

YO, add me as a contributor via the Settings menu (far right on menu bar)

Define hashblock_events

Setup the consistent framework replete with:

• Folder structure supporting automated build, test and execution
• Proto declarations supporting hashblock_chain transaction types and payload content
• Changes to build_all and run_tests to support hashblock_chain

Add Resource TP

Continuous Deployment

Having 1 YAML and 1 Config to deploy and configure the network

Seed assets and transactions on the network

Use quantity and resource units of measure in CLI commands

Currently we enter prime numbers for units in the CLI.

Instead of: 5:2:3 we should be able to write 5 bag(s) of peanut(s)
Instead of: 2:7:13 we should be able to write 2 $ of USD or $2 of USD
Instead of 2:7:13 1:2:3 we should be able to write ratios like 2 $ of USD/1 bag of peanuts

Ideally we can write a reciprocating event as: $10 of USD @ $2 of USD/1 bag of peanuts

Fix unit tests for UOM

Consistent Sawtooth Events for Subscription production

A clean model for generating Sawtooth informational events for subscribing

Document Test Network Deployment

Add Resource Transactions (Proposal/Vote)

Support rescinding a vote in asset-tp

accept
undo
reject

Rule: Can not go from accept to reject... it requires an undo to preceed a re-vote

Authorize transactions on the network

Currently anyone can use sawadm to generate keys for signing transactions and batchs on the network. The identity transaction family and the validator policies must be used to add authentication. The validation policy is set to trust now and it should be set to challenge.

Figure out the basic machinery

Using a hijacked version of intkey-java, prove out development options as well as understand how to get custom TP's, etc. into the ecosystem.

Off network Shell

zkSnark

Move test yaml to compose location

To discuss w/Arthur to determine naming conventions

Document Continuous Build

Refactor family utilities

Create a common design paradigm for listing, proposing, voting, initiating and reciprocating

Setup testing script in bin/run_tests

List reciprocating events

bin/hashblock events list should list reciprocating events with the balancing equation

<event_id> 5 bags of peanuts * $2 of USD/1 bag of peanuts = $10 of USD

Use prime numbers until we can use unit and resource addresses to look up unit codes. Ideally these codes and events are in an off-chain database for fast reads.

Adopt protobuf to new scheme

There are two (2) protos: units (top level) and unit(Proposal, Votes, etc)

Refactor addressing scheme

See Address Scheme in Wiki for details

This will change all TP's as well as genesis block and CLI

Refactor Unit and Resource protobufs

Both have a "list" object that has no value