tangram: an introduction€¦ · 3 about tangram tangram is a global project that aims to inspire,...
TRANSCRIPT
Tangram: An Introduction
December 19, 2018
1
Contents
1 Note 6
2 Abstract 7
3 About Tangram 8
3.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 Design Goals 9
5 A Note on Tangram’s Privacy and Transparency Model 10
6 Overview 10
7 Transaction 12
8 How a transaction is made 12
8.1 masterKey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2 toAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3 Amount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.4 Encrypted memo field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9 Anatomy and lifecycle of a transaction 13
10 Transaction validation 13
11 Hash-based payments 14
11.1 Argon2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.2 Blake2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12 Coin generation 14
13 Offline transactions 14
13.1 Phases of generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.2 Coin(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
14 Redemption Key 16
15 Notification Address 16
16 Merkle DAG 16
16.1 Hash-based scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2
17 Tangram Protocol: zk-PoS Consensus 18
17.1 Zero-knowledge Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
18 PoS-Conditions 21
18.1 Slashing Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
18.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
19 Network 21
19.1 Basic concepts of a gossip protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
19.2 Tor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
19.3 Tor Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
20 Ledger 23
21 Nodes 23
22 Wallet 24
22.1 Balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
23 Proof-of-Work 25
24 Storage 25
24.1 Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
25 Privacy 25
25.1 Privacy of balances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
25.2 Privacy of amounts / transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
25.3 Sealed Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
25.4 Somewhat Homomorphic Encryption (SWHE) . . . . . . . . . . . . . . . . . . . . 26
26 Transaction unlinkability 26
27 Security & Attack Vectors 27
27.1 Double-spending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
27.2 Transaction Flooding / Flood Attack . . . . . . . . . . . . . . . . . . . . . . . . . . 27
27.3 Sybil Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
27.4 Majority Attack (51% attack) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
27.5 Denial of Service (DoS) attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
27.6 Malicious code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
27.7 Nothing-At-Stake Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
28 Miscellaneous 29
28.1 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
28.2 Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
28.3 Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3
28.4 Incentive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
28.5 Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
29 Applications 30
29.1 Wallets / Account(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
29.2 Simple Smart Policy Escrow (Contract) . . . . . . . . . . . . . . . . . . . . . . . . 30
30 Conclusion 32
31 Acknowledgments 33
32 Notes and Further Reading 34
33 Future Considerations 35
References 36
4
List of Figures
1 Privacy and Transparency Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Anatomy of a transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Authentication procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Merkle DAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5 Hash based scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6 Broadcast for N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7 SWIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5
1 Note
*This document will evolve and is subject to updates and changes based on feedback, research,
empirical evidence and analysis. The definitions herein are not intended to be comprehensive or
final. Changes between the original paper and Tangrams’ current implementation will be indicated
in green.
6
2 Abstract
A rapid shift from traceable and non-private peer-to-peer transactions has become increasingly
prevalent in blockchain, next-generation distributed ledgers, and many other applications. Many
individuals and organizations are now discussing the need for a private and/or anonymous ap-
proach. Here we propose a solution which will provide a secure networking platform to enable
private, non-traceable transactions, with on-chain unlinkability, and complete fungibility. Our ap-
proach utilises a blockchain coupled with a Merkle DAG structure for immutable balances at the
time when transactions take place. All user amounts are stored on the ledger, cemented without
ever displaying the balance in plaintext or knowing the sequence of blocks generated from individ-
ual accounts. The ledger provides proof of the user amounts within the network as it builds after
every transaction. This provides transparency of available coins and total coin supply within the
network, as well as providing multi-layered verification and anonymity for consensus. All amounts
and values are broadcast to all other nodes through a gossip based approach within the mixing
network, Tor. While nodes can leave and join the network and clusters at any given time, the
ledger provides proof of coin authorship and ownership. A zero-knowledge Proof of Stake consen-
sus protocol within the network enables trustless transfer of value. This system meets the design
principles of privacy, speed, simplicity, robustness, quality, and low operating cost. Satisfaction of
these criteria lays the groundwork for long-term scalability and future innovation.
Keywords: anonymity, applications, cryptocurrency, distributed ledger technology, financial
privacy, hash-based payments, network application, proof-of-stake, zero-knowledge
7
3 About Tangram
Tangram is a global project that aims to inspire, mobilise, and empower a new generation of free,
fast, and secure digital payments and services. By combining cutting-edge open-source engineer-
ing, compelling user experiences, and branding, we’re working to create the world’s most private
distributed ledger network. Our network and platforms are built with security that is not only use-
ful for governments, financial institutions, and multinational corporations, but also yields zero-risk
and zero-compromise solutions for the everyday individual.
3.1 Privacy
By creating a highly-sophisticated and infinitely-scalable digital payment system that enables busi-
ness, investors, and individuals to make secure and untraceable transactions with unprecedented
speed, while unlocking the unique opportunity presented by the digital age, to take greater control
of their own financial security and wellbeing.
3.2 Technology
The technologies will ensure private transactions remain private, and will eventually grow to a
point where we can support smart contracts, data storage, and communications; starting with a
desktop wallet that offers the banked and unbanked a safe place to spend, share, and store a digital
currency that has enhanced privacy and encryption features.
3.3 Research
With strong commitment to research and development means that we are constantly looking for
new innovative ways to enhance online security, with the long-term ambition of establishing a
revolutionary network of integrated financial and communication-based products, services, and
partnerships that enable individuals, businesses, and investors serve and advance privacy as a
universal human right.
3.4 Education
We believe education is important, especially that based on open-source technology. It provides a
powerful platform to engage, share and connect with thousands of people across the globe. We aim
to provide an authentic and supportive research-based educational practice which enables learning,
teaching and partnering with those that believe in the same goals.
8
4 Design Goals
The following are Tangram’s broad design goals:
• Privacy: create a private distributed ledger technology that is provably impervious to re-
identification attacks.
• Speed: perform verified transactions in under ten seconds.
• Cost: ensure that no fees are associated with transaction execution.
• Security: minimize vulnerabilities, network complexity, and maximize resilience.
• Censorship Resistance: enable anyone to freely and discretely access and utilise the net-
work.
• Transparency: allow for simple verification and auditing of the total coin supply.
• Scalability: support rapid growth and performance improvement as the number of nodes
increase.
• Simplicity: provide applications and APIs that are easy to use, maintain, and evolve.
• Robustness: maintain network function even if the majority of nodes go offline.
• Hardware Independence: allow anyone to be able to send and validate transactions on
any device.
• Quantum Secure/Safe: support future enhancements to address privacy and security risks
related to quantum computing.
9
5 A Note on Tangram’s Privacy and Transparency Model
Many DLT solutions today only allow for verification of coins if a vulnerability is known, such that
a larger-than-stated amount of coins – or even ongoing minting of additional coins is difficult to
detect. To address this specific risk, and to maintain ongoing public trust, Tangram’s total supply
is always verifiable to ensure that all coins are visible in the ledger and can be accounted for.
With Tangram, anyone is able to verify the total supply, and any major exploits such as coin
“minting” will be immediately evident.
All coins are associated with a masterKey. These coins cannot be linked to an individual.
An individual’s total balance cannot be determined, as each coin carries different amounts, never
leading back to an individual’s final balance or transaction history.
Figure 1: Privacy and Transparency Model
6 Overview
The following overview is intended to give a concise summary of the ideas behind the solution,
for an audience already familiar with blockchain-based cryptocurrencies such as Bitcoin. It is
presented as a general overview, not a precise technical description, and is not part of a normative
protocol specification.
All coins associated with an individual are also associated with the masterKey. Individual
balances and transactions from the sender and receiver in Tangram are private. Values of coins are
made transparent, essentially similar to Bitcoin where the total supply at any given time in the
Tangram protocol and/or network is auditable. Balances (which are always considered as ‘data-at-
rest’) are encrypted using a two-level homomorphic encryption scheme, Somewhat Homomorphic
Encryption (SWHE). The owner of the balance is able to encrypt their balance with a ‘true’ value
or a ‘false’ value by creating two separate keys. By default, the ‘false’ balance is set to zero.
All transactions in Tangram are carried out privately, without the balance, value (amount),
sender, or receiver being visible to third parties. A sender must define four properties in order for
10
the transaction to be committed, verified and confirmed. These properties are as follows:
• masterKey
• Notification Address (Base 58)
• Amount
• encryptedMemofield
Once all four properties have been defined by the sender, the transaction is encrypted with an
ephemeral key and the recipient’s public key, and then sent to the messagePool for the receiver to
take ownership of the coins. For this to occur, a redemptionKey must be generated by the sender
and is packed within the sealed box. Once a redemptionKey has been received, the following takes
place:
1. Check if coins exist on the ledger.
2. redemptionKey is used to encode the new coins properties.
3. The coins are then verified through a zero-knowledge proof.
4. New coins are generated once a transaction has been sent, verified and confirmed.
A transaction includes computationally sound zero-knowledge proofs and hashes, which prove that
all of the following hold true (except with insignificant probability):
For each input;
• there is a revealed secretKey with the same value as the input,
• prover authorizes the secretKey of the coins,
• the coins commitments are computed with correctness,
and for each output;
• there is a revealed value commitment of the same value as the output coins,
• redemptionKey is computed correctly,
• it is infeasible for any coin to have exactly the same properties as any other.
During the sendPayment function, an explicit coin(s) check is included to verify that the amount
being sent is valid and proven to be the sender’s. (No balance check is required.)
In addition, various measures are used to ensure that the transaction cannot be modified or
tampered with either while the transaction is in transit or ‘at rest’ with the receiver or third
party. Aside from zero-knowledge - Proof of Stake, the transaction is validated when the following
requirements have been met:
1. notificationAddress and its contents are those defined by the sender for the receiver.
11
2. redemptionKey and its properties match for both the sender and the receiver.
3. The coins and their contents are consistent with those in the Merkle Tree.
4. Receiver encodes the coins with the two secrets shared by the sender.
5. Ownership is only transferred once the receiver has proof that the coins are valid, owned (by
the sender), and verified (zero-knowledge-proof).
The properties of the coins inherently prevent double-spending. Each coin on the ledger has these
properties which are unique to the coin, and attempting to spend a coin twice without revealing
the secretKeys would reveal to other nodes that the coin and its properties already exist or invalid,
thereby invalidating and ignoring the transaction.
7 Transaction
The term ”transaction” is used in Tangram to refer to the data transferred object when sending
data from an external “account” which contains:
• masterKey: used to generate, pass ownership, and secure stack of coins.
• toAddress: the recipient of the coins.
• amount: amount to transfer from the sender to the recipient.
• encryptedMemofield: optional user data field, which can be used to insert some form of
proof of association of sender.
8 How a transaction is made
An individual executes a transaction (send) on the client (wallet) side and defines all the prop-
erties that a coin generates as outputs. Thus, the actual computation behind the transactions is
performed by the individual (sender), and the traces forming the transaction already contain the
output objects, return parameters, and the information required to validate the coins through the
network and its algorithm. This design pattern is related to traditional optimistic concurrency
control.
The following are input fields needed for an individual to send value:
8.1 masterKey
masterKey is created from an Argon2 function and thereafter mixed with several properties to
create the associated subKeys. subKeys are then hashed using Blake2b.
8.2 toAddress
An address is a public key which is encoded to a base58 string.
12
8.3 Amount
Stack of coins which are associated with an individual’s masterKey. An individual can have multiple
stack of coins with different values associated, which make up an individual’s account balance.
8.4 Encrypted memo field
An optional data field named “encrypted memo field” is made available to the sender of a transac-
tion. The encrypted memo field is present in every transaction, and is always exactly 64 bytes long,
which is equivalent to 64 characters. If the encrypted memo field does not use the full data field
(64 bytes), the remaining bytes will be padded with the ISO/IEC 7816-4 padding algorithm. [1] If
the sender does not input any data (text) within the encrypted memo field, the memo will be sent
with random values (prior to encryption).
Padding is necessary for privacy, so that when an observer tries to decipher the contents of the
encrypted memo field, there is no obviously discernible difference; no patterns from transaction to
transaction; and the data being transmitted is consistent with that of others.
The encrypted memo field is only visible to the recipient, as the sender encrypts using the
recipients publicKey (pK). Only the recipient can decrypt the encrypted memo field.
9 Anatomy and lifecycle of a transaction
As described above, the following figure visualizes the transaction lifecycle of a sendPayment for a
given input, along with the properties for each step of the send process.
Figure 2: Anatomy of a transaction
10 Transaction validation
Execution and validation of transaction(s) are done locally. The signed transaction is submitted
to your local Tangram node. Local and validating node(s) will validate the signed transaction to
ensure it has been signed by the sender.
Validation procedure for sendPayment:
13
• Verify coins
– Verify Hint
– Verify Keeper
– Verify Principle
– Verify Stamp
• Verify notificationAddress
• Verify zero-knowledge proof
11 Hash-based payments
Hash-based payments are simply a payment system consisting of hashes. The algorithms which
are incorporated are Argon2 for the masterKey derived function and proof-of-work, and Blake2b
to secure the Merkle DAG.
11.1 Argon2
Argon2 is a password-hashing function that summarizes the state of the art in the design of
memory-hard functions, and can be used to hash passwords for credential storage, key derivation,
or other applications. [2]
11.2 Blake2b
BLAKE2 (also known as Blake2b) is a cryptographic hash function which is faster than MD5,
SHA-1, SHA-2, and SHA-3, yet is at least as secure as the latest standard SHA-3. BLAKE2 has
been adopted by many projects due to its high speed, security, and simplicity. [3]
12 Coin generation
Any coin(s) received are “challengeable” on the client side. A challenge is referred to as a response
from the server side which questions the client side, asking for proof as to whether the sender has
the requested properties and amount.
The sequence of the coins has a subset that constitutes a serial number defined by an amount
with a secured random key, and thereafter execution of a zero-knowledge proof.
13 Offline transactions
A receiver is able to claim their coin through many channels, as mentioned previously. One of the
ways in which this integrates well with the Tangram network is that the receiver is able to claim
their redemptionKey through the messagePool and thereafter feed this within their client (wallet).
This enables the individual to decrypt the data, and because the redemptionKey provides zk-proof
14
of the coin, it may index the ledger download the data needed to take ownership, and then the
challenge will proceed.
13.1 Phases of generation
All coins are generated within the genesis block. Stack of coins are associated with an individual’s
masterKey, which (again) is a key derived function. If any subKeys are compromised, it does not
lead back to any other subKeys or the masterKey itself. The remaining attributes of the coin are
used to derive key functions to create hashes on top of hashes, which enable the coin to go through
a process of storage and incorporation into the Merkle DAG. If any coin is not authentic and does
not have the necessary property requirements during the phases of the ( get) and ( set) functions,
the coins are disregarded, and the ownership and authorship of the coins in question are invalid
and ignored. masterKey provides the need to prove that you are the owner and also that the coins
are authentic.
13.2 Coin(s)
To authenticate ownership of the coins, the individual must provide the Hint, Keeper, Principle,
Stamp (zero-knowledge-prover), Amount (which is associated with your masterKey) and Serial
(which is derived from the amount and masterKey). The procedure of ownership and authenticity
needs to be zero-knowledge verified on the server side.
Below describes the authentication procedure for sending a coin(s):
Figure 3: Authentication procedure
All coins are associated with the masterKey, and the unique properties and fields are also derived
from it. Creating associated hashes for each property, the properties provided in conjunction,
creates these unique one-time hashes. Ownership must be demonstrated by providing proof of
the same sequence, generation of the derived keys, and hashes in order for verified zk-proof of
ownership is associated with a particular masterKey.
Each Principle within an execution of a sendPayment is always a different key (unique) during
the ownership transfer of the coins. This provides for a multi-layered security and authentication
process to verify coins author and ownership.
15
14 Redemption Key
Each redemptionKey is derived from the masterKey, which creates two subKeys. Both subKeys
are used for the receiver to take ownership of the coins that have been sent. Once an individual
has received the coins, the coins are encoded with the individual’s masterKey.
Two properties make up a redemptionKey:
• Proof of coins - amount and serial.
• Two secretKeys, encoded by the masterKey.
15 Notification Address
A notificationAddress occurs when a SendPayment has been executed. The purpose of the no-
tificationAddress, is so that the receiver is able to receive coins from a publicKey (pK) that the
receiver has created. This is considered as a sharedKey amongst the sender and receiver. This
increases the level of anonymity between the sender and receiver.
Sample:
1 var notificationAddress = cryptography.GenericHashWithKey(Utilities.
BinaryToHex(bobPk.ToArray()), sharedKey);
Code Snippet 1: A notificationAddress in code
16 Merkle DAG
The underlying structure of the network, the Merkle DAG, is a network of interrelated hashes which
secure a Merkle Tree structure. Furthermore, the structure is based on the data of coins, which
increases privacy and introduces the necessity of fungibility and sharding. There are embedded
DAGs within the architecture as well; for example, assuming 256 “chains” within each chain, an
individual is able to store, transfer and accept amongst other chains - this creates a chain-within-
chain network.
Separation of chains increases the possibility of sharding based on dynamic variables and caters
to optimisation for load balancing.
A simplistic representation of a Merkle DAG structure. Although the interpretation of the lines
as straight, and linkability seems assumed; this is not necessarily the case, yet all transactions do
indeed always flow forward temporally.
16
Figure 4: Merkle DAG
17
16.1 Hash-based scheme
Hash-based scheme refers to cryptographic hash functions, particularly the cryptographic hash
functions employed by Argon2 and Blake2b; each output is unique to a given input.
Figure 5: Hash based scheme
• V defines the version number of the coin
• A defines the amount associated with the coin
• P defines the proof that the coin is the owner’s and is authentic
• H defines the generation once a sendPayment has been executed
• K defines the key to the coin for an individual to take ownership and association with the
masterKey
17 Tangram Protocol: zk-PoS Consensus
The Tangram Protocol utilizes a decentralized consensus algorithm capable of meeting the privacy,
security, speed, and scalability requirements for the network, namely zero-knowledge Proof of Stake
through staking and voting dissemination. The goal of zero-knowledge Proof of Stake is to allow
a receiver direct proof of ownership of the coin being sent without involving a trusted third party
in the protocol. Tangram Protocol has properties that dynamically define the quorum. We follow
a leaderless Practical Byzantine Fault Tolerant (BFT) consensus similar to Blockmania. [4]
We randomly select n nodes to form a group of n random validators to form the consensus group,
these n validators will determine their ‘stake’ in order to join the voting and validation procedure.
When ‘staking’, the nodes selected and proved to have x coins defined to be ‘staked.’ There ‘stake
is locked and the redemptionKeys for each validator are submitted to an ‘escrow’/ messagePool.
‘Stake’ can also be delegated (stake cannot be used or spent by the delegated party), their weight is
determined for each n nodes based on the amount of ‘stake’ which is verified through a commitment
scheme using Shnorr protocol. Once the epochs have been received and stored within the node,
the stored transaction is signed using the privateKey of the receiver (Only receiver is able to sign)
while a coin’s properties need to exist and be valid in the sequence in which they were produced
18
in order to be proved. The zk-proof will then return ‘true’ for the property of the coins. Once
signed, validators will broadcast to other group(s) within the network.
With respect to Practical Byzantine Fault Tolerance (PBFT) the abstract events exchanged
are pre-prepare, prepare, commit, view-change and new-view (there are no messages relating to
check-pointing). Each node must maintain a state per decision it needs to reach: namely, a current
view number view n. The initial view number is zero and the message sets are empty. [4]
Figure 6: Broadcast for N
Every node can include the following messages:
View change (vc): Triggered upon a logical or physical time-out, for no advancement and
contains the latest events.
New view (nv): When view change is triggered, the state moves to new view with all view
change events.
View number (vn): A list of input messages in n and output messages out n
Pre-prepare (pp): For when a block is created.
Prepare (p): Defined when pre-prepare and view are triggered to accept.
Count for prepare (c): Resulting once a pre-prepare message is created and forwards to all
nodes (by random).
Commit messages (cm): Nodes that receive the prepare messages first, issue a commit
message to other nodes
Deliv: Delivery decision being received.
19
17.1 Zero-knowledge Proofs
We use Schnorr Protocol for Non-interactive Zero-Knowledge Proofs to allow for values not being
revealed, during ‘staking’ and value transfer. The Schnorr protocol is an example of a Sigma
protocol, which has the following properties:
Completeness: if the statement is true, the honest verifier (that is, one following the protocol
properly) will be convinced of this fact by an honest prover.
Soundness: if the statement is false, no cheating prover can convince the honest verifier that
it is true, except with some small probability.
Zero-knowledge: if the statement is true, no cheating verifier learns anything other than this
fact. This is formalized by showing that every cheating verifier has some simulator that, given only
the statement to be proved (and no access to the prover), can produce a transcript that ”looks
like” an interaction between the honest prover and the cheating verifier. [5]
Usage of the coin(s) properties will be made to verify and prove, hiding the elements that link
and trace a coin either to a sender and / or a receiver.
The protocol is a three-step protocol between the prover (P) and verifier (V). Which follows
the below:
• P -> V: commitment
• V -> P: challenge
• P -> V: response (proof)
The protocol is defined for a cyclic group of order n.
The prover commits to a random private value v, chosen in the range [1, n-1]. This is the first
message commitment = G * [v].
The verifier replies with a challenge chosen at random from [0, 2ˆt - 1].
After receiving the challenge, the prover sends the third and last message (the response) resp
= (v - challenge * a) mod n.
The verifier accepts if the prover’s public key, P, is a valid public key. It means that it must
be a valid point on the curve and P * [h] is not a point at infinity, where h is the cofactor of the
curve.
The prover’s commitment value is equal to G * [r] + P * [challenge] [6]
1 testSchnorrNIZK :: IO Bool
2 testSchnorrNIZK = do
3 −− Setup
4 let curveName = Curve25519
5 basePoint = Curve.g curveName
6 keyPair@(pk, sk) <− genKeys curveName basePoint −− Prover
7 proof <− Schnorr.prove curveName basePoint keyPair −− Verifier
8 pure $ Schnorr.verify curveName basePoint pk proof
Code Snippet 2: An example of the Schnorr protocol for Non-Interactive Zero-Knowledge Proofs
looks as follows:
20
The Schnorr implementation in Tangram will use Curve25519.
18 PoS-Conditions
The algorithm (consensus) is as follows and operates in epochs of r rounds each ; *a secure
commitment scheme is used for transaction(s), each contains a zk-proof which verifies
the amount using a random group of n validators:
18.1 Slashing Conditions
If the ‘stake’ of the validator is discovered to be malicious (i.e. certain set conditions are contra-
vened), the ‘stake’ will be distributed to the n random validators which participated during the
consensus process based on their weight of ‘stake’.
Note: in systems such as Ouroboros, [7] nodes are associated with some ‘stake’ which may
be an arbitrary value, however needs to follow the model of being unforgeable and transferable.
Decisions on consensus are based on the amount of ‘stake’, a node possess, and in such cases are
all probabilistic guarantees.
18.2 Performance
Upon going live with the Tangram network, performance will be measured by the number of
transactions and finality of consensus being reached.
19 Network
Tangram uses a gossip protocol to manage memberships and events of nodes organized in an
arbitrary way. The organization of the nodes is referred to as the network topology. Our topology of
choice is based on “SWIM: Scalable Weakly-consistent Infection-style Process Group Membership
Protocol”. [8] As such, the gossip protocol is used for membership, disseminating relevant meta-
data, transactions, and consensus amongst nodes in the network.
Any n nodes are free to join and leave a membership list/pool. Some nodes may even fail to
respond to requests or disseminate data.
Join process: When a member wishes to join the network, join messages are broadcasted and
group members within a cluster who are listening for join messages reply.
Leave process: The same procedure takes place when newly members join or members who
voluntarily leaves.
Failed process: Once Alice has detected that Bob is failed, she notifies her membership
list/pool. The members within this group delete Bob from their membership list.
N nodes periodically broadcasts to other nodes at random and disseminate accordingly, and
issue information at regular intervals. N nodes that broadcast, also listen to requests (reqs) from
all other n nodes within the network and respond with any events requested (ping-req), essentially,
all nodes gossiping events.
21
19.1 Basic concepts of a gossip protocol
There are two important components in the SWIM protocol:
1. Failure Detection Component, that detects failures of members
2. Dissemination Component, that disseminates information about members that have re-
cently either joined, left the group, or failed.
Both components work together sequentially in order to ensure four key characteristics meet the
composition of failure detection protocols.
1. Strong Completeness: crash-failure of any group member is detected by all non-faulty
members
2. Speed of failure detection: the time interval between a member failure and its detection
by some non-faulty group member
3. Accuracy: the rate of false positives of failure detection;
4. Network Message Load, in bytes per second generated by the protocol.
Furthermore, we introduce the usage of Off-the-Record Messaging Protocol. OTR assumes a
network model which provides in-order delivery of messages, but that some messages may not get
delivered at all (for example, if the user disconnects). There may be an active attacker, who is
allowed to perform a Denial of Service attack, but not to learn the contents of messages. [9]
We use OTR for communication between nodes and when events are propagated within the
network using gossip protocol.
19.2 Tor
We integrate the Tor Onion Service Protocol (formerly known as “hidden services”) at the trans-
port layer to secure and improve anonymity of the network traffic between the nodes in Tangram.
Ultimately this circumvents others learning an individual’s location (IP address) while using Tan-
grams network. By default, obfs4 will be active and all nodes and wallets utilise Tor proxy.
19.3 Tor Load Balancer
Tangram utilises the free, open-source Tor network based shell script called SPLITTER. This
script configures and applies a systematic chain of free open-source solutions which work together
to obfuscate traffic correlation analysis and increase the difficulty of statistical attacks within the
Tor network. It also assists with related de-anonymization techniques, while ensuring a better
performance for the Tor network and its users. [10]
22
Figure 7: SWIM
20 Ledger
The Tangram Ledger is in many ways similar to the Bitcoin blockchain from a design goals per-
spective, although there are many differences that define the structure and configuration. With
regard to transactions, the primary difference from all other currency blockchains and DAGs; is
that Tangram does not store transactions, only coins.
21 Nodes
Nodes are network servers composing the infrastructure and can be considered as processing plants.
Nodes are able to join, leave and process events from within their own cluster, or the entire network.
Wallets must be attached to nodes in order for payment confirmation to propagate across the
network. It is important to note that nodes only process wallet transactions, but never do the work
of the wallet. Their usage is purely to provide the link between coins verification and the ledger.
Accounts/wallets pre-compute and provide the node with all the information needed to process the
required data to be added to an individual’s masterKey, also providing the zero-knowledge proof
23
and verification.
22 Wallet
Wallets are external to nodes and emit transactions that need to be agreed upon. Wallets may
connect to any node within the network that they are aware of or that is made visible to the public.
The Tangram Command Line interface (CLi) wallet uses HashiCorp’s Vault Enterprise, which
is completely free and open source to manage, secure and control your keys and data. HashiCorp
Vault Enterprise is Federal Information Processing Standard (FIPS) 140–2 Compliant.
The following features have been integrated in Tangram’s CLi wallet:
• Unseal vault.
• Create wallet.
• Create addresses associated with wallet (identifier).
• Get a list of addresses associated with the wallet (vault).
• Check wallet balance.
• Transfer TGMs from sub-addresses or external addresses.
• Set the node which your wallet communicates with (either one you own (recommended), or
one owned by a third party.
• Exit and seal the vault.
• Help - get a list of available commands in the Tangram CLi wallet.
The Wallet utilizes two types of Vault policies, a wallet service policy, and a wallet user policy.
The wallet service policy is utilized by the wallet to allow the user to create new wallets and give
a list of existing wallets; it can be thought of as a “management” policy. The wallet service policy
does not have access to a user’s wallet or any secrets thererin. When a new wallet is generated a
user is created and a wallet user policy is attached to it, the wallet user policy gives the user access
to their wallet “secrets.” When a user authenticates with their credentials Vault will give them an
authentication token which has a “lease” associated to it. The user can access their Wallet data
while the lease is not expired. Once the lease is expired, the user will not be able to access their
wallet data and will need to re authenticate with their wallet credentials.
22.1 Balance
Defines the amount of coins associated with your masterKey and relevant subKeys / “addresses”.
Balance is kept within the Tangram CLi wallet and is never readable or present on the ledger.
24
23 Proof-of-Work
Hashcash like proof-of-work is used for spam protection and short computational operations.
To determine the proof-of-work difficulty for transactions, we have coupled below variables
which may be tweaked where necessary:
1. Cost of time: which defines the amount of computation realized and therefore the execution
time, given in number of iterations.
2. Memory consumption and cost: which defines the memory usage, given in kibibytes.
3. Parallelism of proof-of-work: which defines the number of parallel threads
4. Random string: which is generated by the node.
24 Storage
The size of each transaction is 390 bytes. The data length / size for each event is listed below
*table will be updated on further events:
Name Length (bytes)
masterKey 64
Coin 390
redemptionKey 300
Cipher 446
encryptedMemofield 64
24.1 Speed
Empirical analysis will be done, once a live network has been released with real-world statistics.
The following speeds will be taken into consideration and updated in this document:
• Transaction
• Confirmation Zero-knowledge (prover and verifier)
• Node synchronisation
• Broadcasting
25 Privacy
The mere use of one-time subKeys (which are generated from your masterKey) by businesses,
organisations and other entities accepting payments provides a greatly increased level of privacy.
25
25.1 Privacy of balances
The balance of an individual’s account is never revealed nor is it visible on the ledger. Balances
are encrypted at all times. Balances are only ever needed to allow an individual to view, rather
than the entire balance verification or validation needing to take place when sending a transaction.
25.2 Privacy of amounts / transactions
Amounts that are transacted are not combined or displayed as a single transaction send, nor are
the sender and receiver revealed to a third party observer. What can be observed by the public
on the ledger, is stack coins being transacted and ownership being changed.
25.3 Sealed Box
The role of sealed boxes is to anonymously send messages to a recipient given its public key.
Only the recipient can decrypt these messages, using its private key. While the recipient
can verify the integrity of the message, it cannot verify the identity of the sender. A message
is encrypted using an ephemeral key pair, whose secret part is destroyed immediately after the
encryption process. Without knowing the secret key used for a given message, the sender cannot
decrypt its own message later. [11]
Sealed boxes leverage the crypto box construction (X25519, XSalsa20-Poly1305).
X25519: X25519 is an elliptic curve Diffie-Hellman key exchange using Curve25519. It allows
two parties to jointly agree on a shared secret using an insecure channel.
XSalsa20-Poly1305: XSalsa is used for secret-key authenticated encryption and secret-key en-
cryption. Poly1305 is used for one-time authentication.
25.4 Somewhat Homomorphic Encryption (SWHE)
Tangram’s implementation utilizes SWHE, a leveled homomorphic encryption scheme that effec-
tively addresses the challenges of functionality and efficiency in real-world applications. While
supporting robust transactional security, this approach also lays the foundation for eventual con-
version to enable a four-level homomorphic encryption scheme which has the potential to provide
additional functions within Tangram and other real-world applications built on-top of Tangram,
and the eventual transition to full homomorphic encryption.
Somewhat Homomorphic Encryption is used to encrypt the balance of an individual’s account
(never be visible in plaintext) and how much their masterKey stores.
CLi wallet comes with two privateKeys associated with their balance. One key holds a ‘false’
balance, by default the ‘false’ balance is zero, and the second privateKey holds a ‘true’ balance,
which is the actual balance associated with the wallet or masterKey.
26 Transaction unlinkability
Understanding privacy implications such as transaction linkability will be helpful for users inter-
ested in maintaining maximum control over the visibility of their transaction(s) and storing of
26
their coins.
Transactions where Alice sends to Bob, the direct linkability with the coins transfer is broken,
and an individual is able to transfer coins to another without linkability appearing on the ledger.
An individual is able to “walk” the ledger without leaving links to the previous owned coins.
27 Security & Attack Vectors
In the history of Bitcoin and blockchain, there have been a number of incidents, some more
malicious or problematic than others. Each distributed ledger technology project, especially those
built from scratch, brings new challenges and attack vectors, both known and not yet known.
No software, least of all a distributed network, is unconditionally safe or secure, whether that
be the public key cryptography, consensus, protocol or algorithms. Tangram has been designed
to be safe to use and secure for given threat models. The model however can differ in reality and
only be answered with empirical evidence once the software and network are live.
Tangram relies, among other things, on public key cryptography and hash algorithms and thus
may be vulnerable to more known attacks described below. We describe the known attack vectors
in both traditional blockchains and 2nd to 4th generation ‘blockchains’, along with how Tangram
has mitigated these risks as best as possible.
27.1 Double-spending
[Definition] Double-spending is a potential flaw in a digital cash scheme in which the same single
digital coins can be spent more than once.
The properties of the coins are there to prevent double-spending. Each coin on the ledger is
unique and attempting to spend a coin twice and without revealing the secretKeys would reveal
to other nodes that the coins and its properties already exist and invalid, which would cause the
attempted coin spend to be rejected.
27.2 Transaction Flooding / Flood Attack
[Definition] A flood attack is the process of sending thousands of transactions to ”flood” the
messagePool and subsequently delaying other transactions.
Currently rate-limiting prevents transaction flooding, coupled with the proof-of-work function
and fingerprint restriction, which pairs an IP address with a public-key, has a significant deflation-
ary impact on spam.
27.3 Sybil Attack
[Definition] In a Sybil attack, the attacker subverts the reputation system of a peer-to-peer
network by creating a large number of pseudonymous identities, using them to gain a dispropor-
tionately large influence.
Types of Sybil attacks:
• Routing.
27
• Tampering with voting.
• Fair Resource Allocation.
The Tangram protocol makes this attack more difficult in the following ways:
• Completely isolating malicious node(s) from the network.
• Staking and weight associated with staking amount.
• Fingerprint mapping an arbitrary number of public-keys per IP address.
27.4 Majority Attack (51% attack)
[Definition] The ability of someone controlling a majority of the network to revise transaction
history and prevent new transactions from confirming and reaching finality.
In Bitcoin and other PoW blockchains, a 51% attack refers to hash rate; whereas in PoS, specific
to Tangram, in order to achieve a 51% attack, they would need to stake 51% of the network’s ‘stake’.
27.5 Denial of Service (DoS) attacks
[Definition] A cyber-attack in which the perpetrator seeks to make a machine or network re-
source unavailable to its intended users by temporarily or indefinitely disrupting services of a host
connected to the network.
Consensus is done randomly through every round by randomly selected validators. In order for
a DoS attack to succeed, the malicious actor would need to control a large portion of the network.
Nodes enforce per fingerprint and global API rate limits. Nodes that are rejected by their
pairwise member are encouraged to find a new random node to ensure progress.
27.6 Malicious code
[Definition] Malicious code is the term used to describe any code that is intended to cause
undesired effects, security breaches or damage to a system.
If two hash-schemes are found to be malicious or conflicting, one belonging to an honest indi-
vidual and one belonging to a dishonest individual, they would be isolated concurrently and be
verified for inconsistency and go through an audit procedure between random validators.
Scheme Correctness is achieved if the problem generation algorithm produces values that enable
an honest individual to compute encoded output values that verify successfully and correspond to
the evaluation of those inputs. On the other hand, a verifiable computation scheme is secure if a
malicious individual cannot convince the verification algorithm to accept an incorrect output for
a given function and input x. In zk-proof, if completeness is unable to be attained, correctness is
impossible.
28
27.7 Nothing-At-Stake Problem
[Definition] A situation where an individual loses nothing when acting or behaving maliciously
and by doing so, stands to gain by acting in such a manner.
The introduction of stake slashing mitigates the nothing-at-stake problem. It could be argued
that this will not force all nodes to behave altruistically but rather maliciously.
Security Vulnerabilities and Bugs
From the outset, development of Tangram has been engineered with security as a critical
priority. Although no system can be completely secure, every system can be continuously improved
towards that goal.
28 Miscellaneous
28.1 Hardware Requirements
The below hardware specifications are categorised into one (until recommended requirements can
be detailed):
Minimum requirements:
Disk
Space
Down-
load
Up-
load
Memory
(RAM)
System Operating System
Mini-
mum
(TBC) 5MBps 2MBps 512MB Some ARM-based
chipsets
Windows 7/8.x
Mac OS X
Linux
28.2 Mining
There is no mining capabilities such as with Bitcoin and other first generation blockchain tech-
nologies.
28.3 Fees
There are no fees required to transact by or with individuals, business and organisations utilising
the Tangram network or software.
28.4 Incentive
The incentive to running a node is for those who are altruistically motivated in upholding and
supporting a privacy conscious network. Although nodes that commit a sender’s coins and/or
transactions never reveal anything about the sender or receiver, to maximize privacy consider
owning and running your own node. Furthermore, by ‘staking’, if any malicious or dishonest node
is confirmed and valid, the ‘stake’ amount will be distributed amongst the nodes that were selected
to join the consensus.
29
28.5 Units
TGM (tans), which serves the purpose of providing a mechanism for value of transfer, the denom-
inations are as follows:
Unit Abbreviation Decimal Scientific Notation
tan TGM 1 10−0
microTan miT 0.001 10−3
nanoTan naT 0.000000001 10−9
attoTan atT 0.000000000000000001 10−18
Currently “attoTan” will not display to client side (user interface) and may be used at a later
stage.
29 Applications
Tangram is targeting very specific industries short to mid-term. The first category of industry being
financial institutions and the applications that drive them. We believe that there is a fundamental
challenge facing today’s financial institutions: they’re slow and cumbersome, rooted in outdated
technology and methodologies.
The outset Tangram will provide users with more ways of managing, securing, storing, and
controlling their financial status(s).
29.1 Wallets / Account(s)
Create an account instantly that allows for financial freedom and full control of your finances. By
having an account on the Tangram network you can securely, privately, and almost instantly send
value anywhere in the world at any time. There are no minimum balance or fees which would
hinder anyone from creating an account and transacting.
Creating an account is simple:
1. Download the Tangram CLi wallet.
2. Enter a passphrase.
3. Save your masterKey.
29.2 Simple Smart Policy Escrow (Contract)
Multisignature (multisig) refers to a process requiring more than one key to authorize a transaction.
It is generally used to divide up responsibility for possession of bitcoins.10
Tangram allows for a simple ‘smart policy’ escrow that allows for a 2-of-3 (two parties) OR
3-of-3 (third party) multisig escrow service. A simple smart policy escrow example would be as
follows:
1. Alice wants to purchase a service or goods from Bob, however, does not trust Bob.
30
2. Alice sends her coins to Bob, however, she ‘locks’ the coins or provides Bob with a partial
redemptionKey until Bob provides her with the service or goods.
3. Bob needs to provide the service or goods before Alice or the third party releases the coins.
4. Once Bob has provided the service or goods, Alice or the third party is able to share the
second part of the secret for Bob to claim the payment.
*Further applications will be defined in the future.
31
30 Conclusion
Due to the design of the system, ultimately no wallet for storing coins is required which eliminates
the risk of accidental loss of coins. The framework is based on the concept of a hash-based scheme,
which allows for transfer of coins between individuals. Authorship and ownership are provable,
and thus solve the challenge of double-spending and other common issues. Finally, every transfer
of a coin provides complete anonymity to both the sender and the receiver.
32
31 Acknowledgments
We would like to acknowledge and thank everyone involved in the development and growth of the
project.
33
32 Notes and Further Reading
• The EU General Data Protection Regulation: https://eugdpr.org
• Vault by HashiCorp: https://vaultproject.io/
• Tor software for anonymous communication: https://torproject.org/
• Tor Onion Service Protocol: https://torproject.org/docs/onion-services.html.en
• Schnorr-nizk: https://github.com/adjoint-io/schnorr-nizk
• Nothing at stake problem: https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs#
what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed
• Hashcash: http://www.hashcash.org/
• Scalable, transparent, and post-quantum secure computational integrity: https://eprint.iacr
.org/2018/046.pdf
• Off-the-Record Messaging Protocol version 3: https://otr.cypherpunks.ca/Protocol-v3-4.1.1
.html
34
33 Future Considerations
Within the vast (and growing) industry of distributed ledger technology, we limit the scope of
Tangrams future considerations and arbitrarily list a path in the short-term to long-term. We
present some of these milestones for future research and development.
• Optimisations to throughput and scalability enhancements
• Smart Policies / Contracts
• Atomic swaps
• Pruning mechanismCross-chain interoperability
• Privacy preserving technologies (zk-STARKS and others)
• Encryption delegation mechanism(s)
• Inclusion for further mixing networks (I2p)
• Protocol and consensus enhancement and optimization patterns
• ML based network monitoring (for malicious actors) and more
35
References
[1] Libsodium documentation. Padding, 2018.
[2] Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich. Argon2: the memory-hard function
for password hashing and other applications, 2017.
[3] Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O’Hearn, and Christian Winnerlein.
BLAKE2: simpler, smaller, fast as MD5, 2013. Winnerlein, “BLAKE2: simpler, smaller, fast
as MD5.
[4] George Danezis and David Hrycyszyn. Blockmania: from Block DAGs to Consensus, 2018.
[5] Zero-knowledge proof.
[6] Adjoint. Schnorr Protocol for Non-interactive Zero-Knowledge Proofs, 2018.
[7] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A
Provably Secure Proof-of-Stake Blockchain Protocol, 2017.
[8] Abhinandan Das, Indranil Gupta, and Ashish Motivala. SWIM: Scalable Weakly-consistent
Infection-style Process Group Membership Protocol, 2002.
[9] Ian Goldberg. Off-the-Record Messaging Protocol version 3, 2013.
[10] renergr1nch. DcLabs SPLITTER, 2018.
[11] Libsodium documentation. Sealed boxes, 2018.
36