The US Commerce Department is hosting an event that will see discussion on how blockchain tech could be applied to digital copyright.

Scheduled for Friday, the event is being organized by the department’s Internet Task Force, which draws support from the US Patent and Trademark Organization (USTPO), the National Telecommunications and Information Administration (NTIA), the International Trade Administration (ITA) and the National Institute of Standards and Technology (NIST).

The group was founded to explore a range of issues, from copyrights to digital privacy and cybersecurity.

The Commerce Department will be hosting a livestream of the event, a link to which can be found here. According to an agenda published by the Commerce Department, the event is being held at the USPTO’s Silicon Valley office.

The discussion is perhaps not a surprise given the idea that blockchain tech can play a role in digital copyright is being explored by a number of startups. The idea is that creative works can be linked to a transaction or digitized asset on an immutable ledger. From there, the provenance of that work can be traced to its origin.

The one-day gathering, which begins at 13:30 UTC, will include a panel session on "registries and rights expression languages", a discussion that is expected to focus on the use of blockchain tech.

Subsequent breakout sessions will feature blockchain and smart contracts as topics of discussion. And while no specific projects have been listed, the event will include a half-hour technology preview.

The department said in its release:

"We will discuss the potential for interoperability across digital registries and standards work in this field, and consider the relevant emerging technologies (eg, blockchain technology, open-source platforms). We will also explore potential approaches to guide their adoption and integration into the online marketplace."

Though the event signals the Commerce Department’s first public foray into the tech, its representatives have made overtures to the industry. Last summer, representatives from the department notably attended an industry retreat at Bretton Woods.

Image via Shutterstock

Commerce DepartmentCopyrightGovernment

Original author: Stan Higgins

Noelle Acheson is a 10-year veteran of company analysis, corporate finance and fund management, and a member of CoinDesk's product team.

The following commentary originally appeared in CoinDesk Weekly, a custom-curated newsletter delivered every Sunday, exclusively to our subscribers.

Amidst the fanfare of the release of R3's Corda distributed ledger code, another milestone slipped by almost unnoticed – Hyperledger surpassed 100 members.

On its own, the news isn't that important – 100 is, after all, just a number. But combine the two reports, and you unearth a development that could define the future of blockchain.

Hyperledger was created a year ago as a unifying "umbrella" for enterprise blockchain open-source development. Among the participants are blockchain companies (including R3), financial institutions and tech giants.

Its approach so far has been a mix of fusion and fragmentation. The blockchain Fabric was created by blending submissions from founding members IBM and Digital Asset to create a flexible enterprise solution. Hyperledger's explorer tool is the result of combining code from DTCC, IBM and Intel projects.

At the same time as it became open-source, Corda was submitted to Hyperledger, where it will join Fabric, Intel’s Sawtooth and other protocols. Each runs differently, and while all are designed to work with financial transactions, each was created with different criteria in mind.

So it's logical to wonder whether Hyperledger will apply the unification or fragmentation approach to its newest submission.

Will Corda be incorporated into Fabric or Sawtooth? Or will "components" be stripped out to interact with other solutions?

Scattered clues

To see where this could go, we need to step back and look at the open-source business model.

R3 is a for-profit consortium (currently undergoing a financing round) that has open-sourced one of its main technology assets. Why? To expand its ecosystem, and to encourage developers to improve its functionality.

R3 will no doubt charge for related services such as security layers and consulting, and may develop proprietary apps that it can sell to clients.

It therefore needs to be intimately familiar with the underlying protocol, in order to build on it and commercialize the result. R3 is unlikely to consent to the fragmentation of Corda for broader application, or to the technology being incorporated into another protocol (although it probably wouldn’t object to the other way around).

Hyperledger is a not-for-profit group set up and run by the Linux foundation. Their roles are similar: to foster the development of their communities, encourage standardization and add a layer of governance. The foundation has over 200 members, and as well as shepherding Linux, it has a long list of “collaborative projects”.

Hyperledger has already started down that path.

No one blockchain

But as Hyperledger continues to grow, its members’ interests will spread and diverge. The idea of one blockchain for all becomes less feasible, and the necessary investment less practical.

Unlike with the Internet, we probably won’t end up with one technology standard in the blockchain space, however modular. And that may not be not a bad thing.

Instead of creating a hive of ecosystems competing for talent and users, the initial chaos is more likely to encourage innovation and open up virtually unlimited flexibility.

We're already beginning to see the emergence of a sector in which different solutions are starting to think about how to interact with each other.

We are getting a glimpse what the future of blockchain will look like.

Click Here to Never Miss a Weekly Email Again

Future binoculars via Shutterstock

Disclaimer: The views expressed in this article are those of the author and do not necessarily represent the views of, and should not be attributed to, CoinDesk.

CordaHyperledgerR3CEV

Original author: Noelle Acheson

George Samman is a blockchain and cryptocurrency consultant and advisor who recently co-authored a seminal report on blockchain architecture with KPMG.

Here, Samman explains how the consensus algorithm achieved by Raft was finally fixed by its distant relative, Kadena. 

This article covers Kadena’s blockchain. It uses ScalableBFT to offer high-performance (8,000-12,000 transactions per second) with full replication and distribution at previously impossible scales (the capacity for more than 500 participating nodes).

This, along with the multi-layered security model and incremental hashing allow for a truly robust blockchain. Based on Raft and Juno, Kadena embeds a full smart contract language (Pact) into its blockchain that can be run as either public (plain text) or private (double-ratchet encrypted) transactions.

It is a huge step forward in the blockchain space, possibly representing a new-generation of blockchain technology entirely by its introduction of the idea of “pervasive determinism”.

Similar to bitcoin, Kadena’s blockchain is tightly integrated, and understanding what it is capable of, and what these capabilities imply, requires covering a considerable amount of ground. As such, I’ve broken the article into three parts: 1) Introduction & Raft, 2) Kadena’s Predecessors – Tangaroa & Juno, and 3) Kadena’s Blockchain – ScalableBFT, Pact and Pervasive Determinism.

Part 1: Introduction and the Raft Consensus Algorithm

The history behind Kadena is an interesting case study in the new field of blockchain consensus algorithms and distributed computing.

Kadena is a 'distant relative' of the Raft consensus algorithm. The Raft consensus mechanism was followed by Tangaroa (a Byzantine Fault Tolerant (BFT) Raft) and the JP Morgan project Juno (a fork of Tangaroa), neither of which are longer under active development.

JP Morgan’s new blockchain Quorum is very different from Juno and uses a fusion of ideas from sidechains and ethereum – public smart contracts are allowed on the blockchain in addition to private contracts, which are represented as encrypted hashes and replicated via side-channels.

Kadena is the “next generation Juno”. It uses a new, but related, protocol called ScalableBFT that was spawned from the open-source code of the Juno project and was built by the two key developers who built Juno. Before diving deep into Kadena, a brief history and description of Raft and the predecessors to Kadena need to be discussed.

Raft consensus

The Raft consensus algorithm is a single leader-based system for managing a replicated log. It uses a replicated state machine architecture and produces a result equivalent to Paxos, but is structurally different.

Keeping the replicated log consistent is the job of the consensus algorithm.  In this model, the leader does most of the work because it is issuing all log updates, validating transactions, and generally managing the cluster. Raft consensus guarantees a strict ordering and replication of messages.  It does not care what the messages contain.

A new leader is elected using randomized timeouts, which are triggered if a follower receives no communication from the leader before the timeout fires.  These are called "heartbeats".

If the follower receives no communication over this time period, it becomes a candidate and initiates an election.  A candidate that receives votes from a majority of the full cluster (nodes in the network) becomes the new leader.  Leaders typically operate until they fail.  The heartbeats are sent out to make sure the leader is still there; if nothing is received a new election takes place.

The following stages are how Raft comes to consensus:

A cluster of Raft node servers is started with every node launching as a "Follower". Eventually, one node will timeout, become a candidate, gain a majority of the votes and become the leader. Each node stores a log containing commands. It is the Leader’s job to accept new commands, strictly order the commands in its log, replicate its log to its followers, and finally inform followers when to commit logs that they have replicated. The consensus algorithm thus ensures that each server’s logs are the same order. Logs are “committed” when they have been replicated to a majority of nodes. The leader gathers the replication count and, upon a majority being seen, commits its own new log entries and informs its followers to do the same. Upon “commit” the command in each log entry is evaluated by a State machines. Because Raft is indifferent to the body of the command, any state machine can process committed entries. Moreover, consensus assures that command execution always takes place in the same order as the commands come from the Log which is strictly ordered. State machines will remain consistent as long as command executions are deterministic. When a client sends a command to one of the servers, that server will either forward the command to the leader or is the leader. The leader collects the new command, assigns it a Log Index, encapsulates it in a Log Entry, and adds the command to the uncommitted portion of its log. Whenever the leader has uncommitted entries, it replicates this portion of the log to its followers. When the leader is informed of successful replication by a majority of the cluster, it commits the new entries and orders its followers to do the same. Whenever a new log entry is committed consensus about this entry has been reached. It is then evaluated by the state machine on each server. From this point on, Raft is finished and implementers can decide how to handle responses; replying to the client or waiting for the client to query for the result.

Responses to the client are generally asynchronous.

The Raft consensus protocol is just that – a consensus algorithm. It does not have a notion of and is, by default, fully open to any client issuing commands. The only participation restriction it makes is on what nodes exist at a given time.

Moreover, the leader has absolute authority over the cluster and orders the followers to replicate and commit. It does not assume Byzantine attacks, it needs to only handle crash faults, because nodes are assumed altruistic.

Part 2: Kadena’s Predecessors – Tangaroa and Juno

Tangaroa: The first step towards a BFT Raft

Tangaroa is Byzantine Fault Tolerant (BFT) variant of the Raft consensus algorithm inspired by the original Raft algorithm and the Practical Byzantine Fault Tolerance (PBFT) algorithm.

Byzantine fault tolerance refers to a class failures caused by malicious nodes attacking the network.  If some of the nodes go down it is imperative for the network to continue running without stopping.

In standard Raft, you need to replicate a log entry to a majority of nodes in the cluster before committing it. For BFT consensus algorithms, including Tangaroa, the required cluster size is at least 2f + 1, where f is the number of failures you want to tolerate (including both crashed nodes and compromised nodes). Consensus is achieved by a majority vote of the cluster; if f <= 3 then cluster size = 7 and non-byzantine nodes = 4. Some BFT protocols can even require 3f+1.

A Byzantine Leader can decide to arbitrarily increase the commit index of other nodes before log entries have been sufficiently replicated, thus causing safety violations when nodes fail later on. Tangaroa shifts the commit responsibility away from the leader, and every node can verify for itself that a log entry has been safely replicated to a quorum of nodes and that this quorum agrees on an ordering.

Tangaroa allows clients that interrupt the current leadership if it fails to make progress, in the same way that other BFT Consensus algorithms allow to client to behave as a trusted oracle to depose certain nodes. This allows Tangaroa to prevent Byzantine leaders from starving the system but is very trusting of the client.

Leader election and stages

Tangaroa uses Raft as the foundation for consensus; thus there is a single leader.  In Tangaroa, as in Raft, each node is in one of the three states: leader, follower, or candidate.

Similar to Raft, every node starts as a follower, one of which will eventually timeout and call an election. The winner of the election serves as the leader for the rest of the term; terms end when a new leader is elected. Sometimes, an election will result in a split vote, and the term will end with no leader. In this case, a follower will again time out (timeouts are reset when a vote is cast or an election is called) and start the voting process again.

To begin an election, a follower increments its current term and sends RequestVote (RV) Remote Procedure Call (RPCs) in parallel to each of the other nodes in the cluster asking for their vote. The RPCs Tangaroa uses are similar to Raft’s RPCs with the exception that every RPC is signed and validated via PPK signatures.

RPCs allow for a data exchange between different computers residing on a network and the signatures allow for receiving nodes to verify which node sent the RPC in addition to allowing any node to forward any other node’s RPC at any time.

When a Tangaroa node receives a RV RPC with a valid signature, it grants a vote immediately only if it does not currently have a leader (only occurs at startup). Otherwise, it begins the process that Tangaroa calls a “LazyVote.”

The purpose of a LazyVote is to protect non-Byzantine Followers from electing a new leader when the leader is not faulty; without lazy voting, a byzantine node could trigger repeated elections at any time and starve the system. When a new RV is received by a follower, it saves the RV and waits for all of the following conditions to be met:

a) The follower’s election timeout triggers fires before it handles a heartbeat from its current leader. If a heartbeat is received, the LazyVote is cleared.

b) The RV’s new term is greater than its current term.

c) The request sender is an eligible candidate (valid PPK signature and the client hasn’t banned the node).

d) The node receiving the RV has not voted for another leader for the proposed term.

e) The candidate shares a log prefix with the node that contains all committed entries. A node always rejects the request if it is still receiving heartbeat messages from the current leader, and it ignores the RequestVote RPC if the proposed term has already begun.

If a RequestVote is valid and for a new term, and the candidate has a sufficiently up-to-date log, but the recipient is still receiving heartbeats from the current leader, it will record its vote locally, and then send a vote response if the node itself undergoes an election timeout or hears from a client that the current leader is unresponsive.

Under lazy voting, a node does not grant a vote to a candidate unless it believes the current leader is faulty.  This prevents nodes that start unnecessary elections from gaining the requisite votes to become leader and starve the system.

Nodes wait until they believe an election needs to occur before ever casting a vote. Once a vote is sent, the node will update its term number. It does not assume that the node it voted for won the election however, and it will still reject AppendEntries (AE) RPCs from the candidate if none of them contain a set of votes proving the candidate won the election. AE’s serve the dual purpose of heartbeats and carriers of new log entries that need replication. The candidate continues in the candidate state until one of the three things happens:

a) It wins the election by receiving a majority vote from the cluster. A candidate must save these votes – RequestVoteResponse (RVR) RPCs – for future distribution.

b) Another node establishes itself as a leader

c) A period of time goes by with no winner (ie: it experiences another election timeout)

A candidate that wins the election then promotes itself to the leader state and sends an AE heartbeat messages that contains the votes that elected it and the updated term number to establish its authority and prevent new elections. The signed votes effectively prevents a byzantine node from arbitrarily promoting itself as the leader of a higher term. Moreover, each follower performs a recount on the aforementioned majority vote, validating and counting each vote the new leader transmitted to independently verify the validity of the election.

Governance

Like Raft, Tangaroa uses randomized timeouts to trigger leader elections. The leader of each term periodically sends heartbeat messages (empty AE RPCs) to maintain its authority. If a follower receives no communication from a leader over a randomly chosen period of time, the election timeout, then it becomes a candidate and initiates a new election.

In addition to the spontaneous follower-triggered elections, Tangaroa also allows client intervention: when a client observes no progress with a leader for a period of time called the progress timeout, it broadcasts UpdateLeader RPCs to all nodes, telling them to ignore future heartbeats from what the client believes to be the current leader in the current term. These followers will ignore heartbeat messages in the current term and time out as though the current leader had failed, starting a new election.

Data received

The data (new commands) come from clients of the Raft cluster, which send requests to the leader. The leader replicates these requests to the cluster, and responds to the client when a quorum is reached in the cluster on that request.

What constitutes a "request" is system-dependent. How data is stored is system-dependent. It's important for state to persist to disk, so that nodes can recover and remember information that they have committed to (which nodes they voted for, what log entries they have committed, etc). Without this, the protocol will not work.

Tangaroa adds BFT to Raft evolution

Juno

The JP Morgan project Juno is fork of Tangoroa and was a proof of concept that was able to scale Tangaroa to include up to 50 nodes and raise transaction speed up to 5,000 transactions per second.

The JPM team behind Juno saw the potential that a Tangaroa-like approach represented – a high performance private blockchain. They iterated on the idea for a year and open sourced the project in February 2016. They added a smart contract language, fixed some design mistakes and succeeded in achieving a 10x performance increase which allowed for the number of nodes to vote to change while the system was running. Juno allowed for the adding and removing of nodes, and was a permissioned distributed system in which all of the nodes in the network were known.

The stages of the mechanism and the leader election process are the same as Tangaroa (see above). Similarly, a transaction is considered live once it is fully replicated and committed to the log.

The leader decides the order of the commands and every node validates.  Each node independently decides when to commit a log entry based on evidence it receives from other nodes.  Every log entry is individually committed and incrementally hashed against the previous entry.  It takes approximately 5ms for a single log entry to go from leader receiving the entry to full consensus being reached and network latency.

Part 3: Kadena’s Blockchain – ScalableBFT, Pact, and Pervasive Determinism

Cryptography

Different to Raft, each replica in a BFT Raft system (a family of algorithms that include Tangaroa, Juno, and Kadean’s ScalableBFT) computes a cryptographic hash every time it appends a new entry to its log. The hash is computed over the previous hash and the newly appended log entry.

A node can sign its last hash to prove that it has replicated the entirety of a log, and other servers can verify this quickly using the signature and the hash. BFT Raft nodes and clients always sign before sending messages and reject messages that do not include a valid signature.

BFT Rafts use Incremental Hashing enabling nodes to be certain that both the contents and ordering of other node’s logs match their own. Using this knowledge, nodes can independently commit log entries safely because both the contents and ordering of other node’s logs attested to via matching incremental hashes.

BFT Rafts uses digital signatures extensively to authenticate messages and verify their integrity.  This prevents a Byzantine leader from modifying the message contents or forging messages and protects the cluster generally from a large number of Byzantine attacks.

Consensus

In Raft, a Leader is elected via randomized timeouts that trigger a Follower to propose itself as a Candidate and request votes. ScalableBFT also does this, but in a cryptographically secured way. For instance, if a Leader becomes unreachable, a timeout would trigger a new election but the election process is robust against Byzantine nodes declaring elections. ScalableBFT fixes the issues that Juno and Tangaroa encountered regarding lazy voting.

The Leader’s only unique capabilities are: 1) ordering of new transactions prior to replication and 2) replicating new transactions to Follower nodes. From that point on, all nodes independently prove both consensus validity and individual transaction integrity.

The removal of anonymous participation is a design requirement for private blockchains, and this allowed for a high performance BFT Consensus mechanism to replace mining. ScalableBFT’s primary addition to the family of BFT Rafts is the ability to scale into the 1000’s of nodes without decreasing the system’s throughput.

Every transaction is replicated to every node. When a majority of nodes have replicated the transaction, the transaction is committed. Nodes collect and distributed information (incremental hash) about what they have replicated and use this information to independently decide when to commit (>50% of other nodes send them incremental hashes for uncommitted transactions that they agree with).

It basically works by doing a majority vote on what to commit. Committing a transaction doesn’t mean it will be executed, just that it has been permanently replicated by a majority of the cluster. Bad transactions, ones that error or have bad signatures, are replicated as well as consensus’ job is to provide perfect ordered replication.

Committing a transaction allows each node to then independently evaluate (parse/decrypt/validate crypto/execute/etc…) each transaction in an identical way. Every transaction gets paired with an output, this can range from “bad crypto” to the output of the smart contract layer (which can also be an error).

Finally, besides the leader replicating new transactions to every node the nodes are more or less independent. Instead of “syncing” they broadcast “I have replicated up to log index N and it has an incremental hash of H” to the cluster and collect this information from other nodes – based on the results from other nodes each node can independently decided if the cluster has replicated past the bar needed to commit (a majority replication for some as of yet uncommitted log index N).

Here’s the subtle part: the incremental hash implies replication of all that came before it. If the leader replicates 8,000 new transactions (which is what it currently does), each node need only distribute and gather evidence for the last transaction of that batch as it implies correct replication of the ones that came before it. Instead of sending 8,000 messages (one for each transaction) that attest to proper replication nodes only discuss the latest transaction.

This is why Kadena needed so much pipelining, because the team figured out how to commit 8,000 transactions at the same speed as committing a single transaction.

ScalableBFT represents a breakthrough in field of BFT consensus as it is the first and only deterministic BFT consensus mechanism that can scale past hundreds of nodes with full replication and encryption. ScalableBFT also provides a unique security model known as pervasive determinism which provides security not just at the transaction level but at the consensus level as well while encrypting each and every transaction using the Noise Protocol (see below).

Kadena uses deterministic consensus

The consensus mechanism is deterministic if the consensus process is fully specified in the protocol and this process does not employ randomness. As was stated above, Raft, for example, uses randomized timeouts to trigger elections when a leader goes down (since the leader can't communicate "I'm about to crash", there's a timeout that trips to prompt a node to check if the leader is down) but the election isn't part of consensus at the transaction level, it is instead a means to finding a node to orchestrate consensus.

ScalableBFT is deterministic and hardened such that:

Nodes will commit only when a majority of the cluster agrees with them The evidence of agreement must be fully auditable at any time When lacking evidence of agreement, do nothing.

Kadena is specifically designed for permissioned networks, and as such it assumes that certain attacks (like a DoS) are unlikely and are out of its control. If one were to occur, the system would either lock (all nodes timeout eventually with but an election would never succeed) or sit idle.

Once such an event ends, the nodes will come back into consensus and things will return to normal. However, in a permissioned network, administrators would have full control and kill the connection causing the issue.

Leader Election

Leader election is very similar to Raft in that any node can be elected leader, every node gets one vote per term, and elections are called when the randomized timeout one of the nodes fires (the timer is reset every time a node hears from the leader).

The biggest difference is that in Raft a node that gets enough votes assumes leadership, whereas in ScalableBFT a node that gets a majority of votes distributes those votes to every other node to demonstrate (in a BFT way) that it has been elected the leader by the cluster.

ScalableBFT’s mechanism fixes issues seen in Juno and Tangaroa, like a “runaway candidate” where a non-Byzantine node has timed out due to a network partition but, because its term has been incremented, it can’t come back into consensus and instead continues timeout then increments its term (“Runaway”.)

Raft consensus guarantees a strict ordering and replication of messages; it doesn’t matter what’s in each message and can range from random numbers to ciphertext to plain-text smart contracts. Kadena leverages the log layer as a messaging service when running in an encrypted context; much like Signal can run Noise protocol encryption over SMS. ScalableBFT runs Noise over a blockchain.

ScalableBFT adds consensus robustness, which the layer that deals with interpreting the messages assumes as a guarantee, but also incremental hashes that assure perfect replication of messages. Noise protocol slots between consensus and smart contract execution, encrypting/decrypting messages as needed; because the messages are ciphertext only some of the normal tricks for avoiding a Cartesian blowup of live tests are needed to run per message without leaking information.

Security model/pervasive determinism

Kadena uses the term “pervasive determinism” to describe “the idea of a blockchain that uses PPK-Sig based cryptography for authorship guarantees (like bitcoin) and is composed of a fully deterministic consensus layer in addition to a Turing-incomplete, single-assignment smart contract layer.

The implications of a ‘pervasively deterministic’ blockchain are rather profound, as it allows for a bitcoin-ledger class of auditability to be extended deep into the consensus layer by chaining together multiple layers of cryptographic trust.

Take as an example a transaction that loads a new smart contract module called “loans”. Say “loans” imports another module called “payments” that is already present in the chain. The successful import of “payments” alone implies the following (with each being fully auditable by cryptographic means):

Who signed the transaction that loaded “payments” What consensus nodes were in the cluster at the time of loading What consensus nodes agreed that the transaction was valid What nodes voted for the current leader at the time of loading Who the leader was Who the previous leader was Etc.

A pervasively deterministic system allows new transactions to leverage not only the cryptographic trust that naturally occurs as transactions are chained together in a blockchain, but also the trust of how those transactions entered the ledge in the first place. In so doing, you can create a system more secure than bitcoin because the consensus process becomes as cryptographically trusted, auditable, and entangled as well, with transaction level executions implying that specific consensus level events occurred and with each implication being cryptographically verifiable.

This provides BFT not just for the consensus layer but for the transaction layer (bitcoin already does this) as well.  This is different from, say, PBFT which assumes that transactions sent from the client’s server are valid which leaves them with an ability to be compromised. Moreover, non-Raft BFTs generally entrust the client with the ability to depose/ban nodes. Pervasive Determinism takes an alternative viewpoint: trust nothing, audit everything.

Allowing ScalableBFT to incorporate pervasive determinism creates a completely paranoid system that is robust at each and every layer via permanent security (ie: a form of cryptographic security that can be saved to disk). It has bitcoin’s security model for transactions, extends this model to the consensus level, and adds smart contracts without the need for mining or the tradeoffs that most in the industry have become accustomed to. It’s a real blockchain that’s fast and scalable.

I asked Will Martino (co-founder of Kadena) for the specifics of how this worked for each layer:

What is your consensus-level security model?

For replication, Kadena uses an incrementally hashed log of transactions that is identically replicated by each node. These agree on the contents of the log via the distributed signed messages containing the incremental hash of a given log index, which are then collected by other nodes and used to individually reason about when a commit is warranted. No duplicates are allowed in the log and replication messages from the leader containing any duplicates are rejected immediately.

We use blake2 hashes and Term number to define uniqueness, allowing clients of the system to not worry about sending duplicates by accident or about a malicious node/man-in-the-middle (MITM) resubmitting commands. We employ permanent security, a PPK-sig-based approach to authorship verification (or any type of approach that can be saved to disk) that is very similar to how bitcoin verifies transactions but at the consensus level (in addition to the transaction level).

This is opposed to ephemeral security which uses secured channels (TLS) for authorship validation – a vastly inferior approach where the question “who sent the transaction X?” is answered not via PPK cryptography but via a consensus-level query because any individual node is incapable of providing a BFT answer.

What is your transaction-level security model?

The ideas of ephemeral and permanent security span both the consensus and transaction level, as it is consensus that hands the smart contract execution layer individual transactions. At the smart contract/transaction level we also use permanent security as well, supporting row level public key authorization natively in Pact.

This is important because ephemeral implies that an attacker is one server away from impersonating an entity; secured channels work by point to point distribution of new transactions by the client/submitter to the cluster nodes over TLS and consensus secures that a given transaction should be committed and replicated. However, if an attacker hacks the client server holding the other end of the TLS connection, they can transact as if they were the client without the cluster being the wiser.

Permanent security, on the other hand, has many keys for individual roles in a given entity thus requiring an attacker to gain access to the individual keys; further, with permanent security the CEO’s transactions are signed with a different key than the Mail Clerk’s transactions vs ephemeral where the “who is sending this transaction” is determined by a “from: X” field.

If the same TLS connection is used to submit both the CEO’s and the Clerk’s transactions, then the authorship and authorization logic is a “because I said so/trust me” model vs a PPK-sig approach where you verify against the appropriate key before execution. Kadena’s blockchain is designed to trust as little as possible; if we knew of a more paranoid or fine-grained approach than row-level PPK signatures we’d use that instead.

What is your confidential transaction model?

We use Double-Ratchet protocol (what Signal, WhatsApp, etc… use for encrypted communications) embedded into the blockchain (encrypted transaction bodies) for multi-party privacy preserving use cases. We work with the notion of disjoint databases via the 'pact' primitive in Pact – they describe a multiphase commit workflow over disjoint databases via encrypted messages.

Smart contracts

Pact is a full smart-contract language, the interpreter of which is built in Haskell. In Kadena, every transaction is a smart contract and the Pact smart contract language is open sourced. Pact is database-focused, transactional, Turing-incomplete, single-assignment (variables cannot be changed in their lifetime), and thus highly amenable to static verification.

Pact is also interpreted – the code you write is what executes on-chain – whereas Solidity is compiled, making it difficult to verify code, and also impossible to rectify security issues in old language versions, once compiled. Pact ships with its own interpreter, but can run in any deterministic-input blockchain, and can support different backends, including commercial RDBMS. In the ScalableBFT blockchain, it runs with a fast SQLite storage layer.

Characteristics of the Kadena Blockchain

The Kadena blockchain contains all these features:

In conclusion, Kadena has developed a fully replicating, scalable and deterministic consensus algorithm for private blockchains with high performance.  This blockchain solution can be a giant leap forward for financial services companies looking to employ a real private solution that remains true to many of the key bitcoin blockchain features without mining (proof of work), anonymity and censorship resistance while catering to the key design features that financial services are craving particularly scalability and confidentiality.

This article was previously published on the Sammantics blog and has been reproduced here with permission. Some edits have been made for style and brevity.

Cogs image via Shutterstock

Disclaimer: The views expressed in this article are those of the author and do not necessarily represent the views of, and should not be attributed to, CoinDesk.

Kadenaprivate blockchains

Original author: George Samman

With so much R&D ongoing in the blockchain sector, it's hard for any new tech to separate from the pack.

In addition to the sheer volume of designs for these new types of financial databases, separating the interesting ideas often requires ample peer review, testing and time. Still, this messy process hasn't stopped tech giants like IBM and JP Morgan from conducting work that rivals the more well-known open-source creations like bitcoin and ethereum in aim and ambition.

While these contributions are grabbing headlines, however, praise across both open-source and enterprise communities has been rare.

Bucking this trend is Intel, which is winning support from even normally fickle technologists for its quieter, and some say, more innovative, approach to reimaging bitcoin's tech for the enterprise.

One of the main contributors to this perception is proof-of-elapsed-time (PoET), a variation on the system that bitcoin uses to ensure that computers in the network agree about which transactions really took place, which it unveiled earlier this year. Perhaps better known to cryptographers, this high-tech tool solves the computing problem of "random leader election," or selecting who will create the next block of transactions.

Despite the lack of attention it's received, however, some veteran technologists consider PoET one of the more novel and radical proposals for how a blockchain network could achieve consensus.

Created by developers at Intel, PoET is notably designed to be used on a certain type of computer manufactured by the tech giant, called trusted execution environments (TEE).

On one hand, proponents argue that it's a more environmentally friendly algorithm than bitcoin's proof-of-work (PoW). On the other, many open-source developers are skeptical that could be widely used, since it requires trust in Intel.

Blockstream principal architect Christopher Allen, whose firm is a member of Hyperledger and one of the largest financial supports of bitcoin development, is one experienced observer that echoes this outlook.

Allen told CoinDesk:

"I'm actually not very impressed with Hyperledger Fabric and I think that Sawtooth Lake deserves more attention.”

Mix and match

One of the reasons Allen thinks so positively about Intel's contribution is that it provides a variety of options and consensus algorithms, which he believes allow users to build a private blockchain to meets their needs.

"Sawtooth as a proof-of-concept demonstrates that you can have multiple consensus algorithms," said Allen. "There's no reason Sawtooth couldn't do PoW or proof-of-stake."

Allen mentioned that the working group has been discussing how to create the best architecture for allowing users to choose from a variety of consensus algorithms.

That's where PoET comes in, as it’s one of the unique blockchain offerings that Sawtooth Lake makes available. Allen described it as a simulation of PoW that might be best used as an alternative for private blockchains.

Since it borrows from PoW's Nakamoto-style consensus, PoET offers some benefits over Practical Byzantine Fault Tolerance (PBFT), a type of consensus algorithm used by Hyperledger, Stellar and others, he said. For one, it scales to a larger number of nodes and is more reliable since it works when larger numbers of nodes aren't available.

One downside is settlement finality: users need to wait for a certain number of blocks before they can be fairly certain that their transaction will be recorded.

But, despite these unique properties, another perspective is that PoET doesn't make sense for either private or public blockchains.

"It's way too easy to create multiple layers of obfuscation that ultimately don't contribute to the underlying security model," said Bitcoin Core contributor Bryan Bishop.

Trust in Intel

The main critique to emerge is that participants would need to use Intel hardware like SGX to execute code in a protected area that can't be inspected or tampered with.

That's how you "know" — in theory — that the blocks filled with transactions will be dispensed at a certain interval, and that those transactions are correct. And you know that it can't be tampered because of cryptography involved.

"PoET uses this special processor capability to regulate block frequency rather than computation," Sawtooth Lake project manager Dan Middleton said, explaining that by using the protected area of the chip, the code is executed as designed.

"This is what enables the return to one-cpu-one-vote," he continued, echoing an idea invoked in Satoshi Nakamoto's bitcoin white paper.

But as for comparisons to PoW, there are notable differences. While PoW enables a trustless system, Bishop called Intel's approach "trust-maximizing".

That's why both Bishop and Allen are skeptical that the consensus algorithm can be used for a public blockchain, like bitcoin or ethereum.

"It's like giving the keys to the kingdom to Intel," as Bishop put it.

"The participants are saying, 'We trust Intel to not cause inflation of the system or otherwise interfere, and we believe Intel would rather shutdown before it would comply with government orders to disrupt a system that uses SGX,'" he said.

Future possibilities

But while this probably isn’t good enough guarantee for decentralization advocates, this isn't stopping Intel's work from emerging as part of the conversation on the conference circuit.

Indeed, it may now be time for the wider market to assess how the idea could be evolved, for instance, for use on other processors.

As far as testing the protocol, a user doesn't necessarily need to purchase a TEE. Middleton added that anyone interested in the protocol can now test how it commits blocks across a distributed network.

Allen contends that the use of TEE is why PoET isn't currently as appealing as the more mature proof-of-work protocol, or maybe one day proof-of-stake, both protocols that enable participation via specific types of computer hardware.

But he agreed that if other hardware vendors implement the new algorithm, this could lead to other possibilities.

"It would be powerful to see a multi-vendor standard for PoET be created someday, for instance in the multi-vendor RISC-V consortium," he said.

Like all ideas, it will be up to the market to decide. However, for now, it seems Intel's work has passed one milestone, graduating to larger dicussion and consideration.

Interstellar image via Shutterstock

Bankingdistributed ledgerIntelProof-of-Work

Original author: Alyssa Hertig

Japan’s central bank is testing blockchain tech but has limited its work to research, according to one of its senior officials.

Deputy governor Haruhiko Kuroda spoke earlier today during the Paris EUROPLACE Financial Forum in Tokyo. In remarks, he spoke about the opportunities and challenges regarding new kinds of technology in finance today.

Earlier this year, Kuroda speculated that blockchain could reshape some financial processes, and in May called on other central banks to pursue research efforts like the ones currently being undertaken by the Bank of Japan. Some of the world's central banks, including those in Canada, Singapore and the UK, have moved in the past year and half to explore possible applications in the areas of transaction settlement and financial monitoring.

Yet according to Kuroda, the Bank of Japan isn’t looking to apply the tech to its own operations, instead focusing squarely on research.

Kuroda told attendees:

“Accordingly, the staff in the Payment and Settlement Systems Department of the Bank are deepening their understanding of such new technologies by test-driving distributed ledgers. Note that these trials by the Bank's staff simply aim to understand the mechanics of DLT, rather than applying it to the Bank's own liabilities or its payment and settlement systems.”

Japan’s financial sector, on the other hand, is putting its past research into action.

Last week, several major Japanese banks released the initial results of an interbank payments trial. According to those involved, the prototype system used enabled cheaper transactions compared to existing methods, setting the stage for further research.

Financial institutions across the Asian-Pacific region have spent much of the past two years investigating the tech, both individually and as part of consortia efforts.

Image via Shutterstock

Bank of Japancentral banks

Original author: Stan Higgins

On 1st December, the state of Illinois took its first step in its ambitious multi-agency plan to guide the integration of blockchain technology into government operations.

The Illinois Department of Financial and Professional Regulation (IDFPR) announced that it has released for public comment its proposed Digital Currency Regulatory Guidance on decentralized "virtual currencies", which is intended to address inadequacies found in the IDFPR’s interpretation of the state’s Transmitters of Money Act.

The release happened at the same time the state’s Department of Innovation & Technology (DoIT) released its Blockchain and Distributed Ledger Request for Information.

The IDFPR and the DoIT – along with the state’s Department of Commerce and Economic Opportunity (DCEO) and Department of Insurance (DOI) and Cook County's Recorder of Deeds – form the Illinois Blockchain Initiative, a first-of-its-kind government collaboration announced on 30th November at the Blockchain Conference Chicago.

The initiative is to serve as a steering committee, designed to propose policy that will address not only the regulation of blockchain technologies in the state, but the simplified incorporation of the technology in government operation.

The DoIT's request reads:

"As with most emerging technologies, the State of Illinois recognizes that the full extent of future use cases will not be defined in the short term. That being said, the State believes it is important to horizon scan, explore, and ask questions. What are the strongest applications of the technology? What is the value proposition? How can we ensure proper safeguards are built in? Is the technology available now?"

The request for information’s response deadline is scheduled for 18th January, with presentations due to be made in Chicago from February to March, 2017.

But while the request presents a wide array of policy areas which the initiative could pursue, the IDFPR’s guidance document paints a need to consider a regulatory scheme to bring the state’s cryptocurrency market in compliance to money transmitter requirements. This is despite appearances that the state is less than optimistic about the potential of this market.

“As innovative payment technologies grow in popularity, it is vital that we provide a succinct regulatory framework that gives businesses operating in this space necessary clarity,” said Bryan Schneider, Secretary of the IDFPR, according to the department’s press release on the guidance document.

According to the statement:

"We plan to study digital currencies carefully as the technology develops, however, at this point in time digital currencies like Bitcoin, given their low transaction volume and relatively niche use, are best viewed as a speculative investment or possibly even a new type of asset class, not as money."

A different approach

The two documents combined give the impression that state-guided innovation in blockchain technology should steer away from FinTech.

Richard Morris is the deputy director of strategy and operational performance for the Illinois Department of Financial and Professional Regulation. "As a department, we have no current or future plans to regulate digital currency," he told CoinDesk.

Morris indicated that he believes the risk posed to consumers by the technology is low at this time, as are the number of cryptocurrency users.

"Digital currencies are still primarily used as a speculative investment as opposed to a true ‘currency’ or money. This is supported by the average amount per transaction, approximately $685 USD sent per bitcoin transaction in October 2016," he said.

In part bolstered by other states’ attempts to regulate cryptocurrencies, Illinois is currently pursuing a "light touch" in regards to modernizing its money transfer regulations.

Calling the IDFPR’s guidance document “an effort to provide businesses operating in this space the regulatory clarity around how we differentiate between the digital currency activities that are custodial and non-custodial and how that relates to sovereign currency,” the IDFPR’s position is to identify sovereign currency transactions – including the potential transfer of sovereign currency through the purchase and sale of cryptocurrency – and properly regard them as money transfer activities, in accordance to the Transmitters of Money Act.

An example given in the guidance document is bitcoin ATMs.

Should the ATM take cash or credit for the sale of bitcoins with the help of a third-party bitcoin exchange, the document argues that the ATM and its operator should be classified as a money transmitter, as defined in the Transmitters of Money Act.

However, if the ATM operator was to deal with the bitcoin customer directly without the help of a third party, no money transfer occurred, per the IDFPR’s interpretation.

According to Morris, the idea was to prevent confusion by creating a "one-size-fits-all" approach to diversely different virtual currency products.

Morris continued:

"We also understand given how inherently different digital currency’s properties are, other states haven’t taken the same light touch approach when it comes to regulating digital currency businesses, which creates uncertainty around who will be regulated, how they should be regulated."

Innovating distributed ledgers

Per the DoIT’s request for information, Illinois is requesting proposals regarding the creation of identity, attestation and ownership registries, which could include land registries and gun registrations; compliance and reporting ledgers, that could be used for voting systems and court records; and benefit and entitlement ledgers, including research grant tracking and social services payments.

“The best way to develop a technology is to put it into practice,” read the request for information. “The State of Illinois is interested in determining if blockchain and distributed ledger technologies could be leveraged to create more efficient, integrated and trusted state services.”

One potential use for non-Fintech blockchains come from Cook County, the county that houses the state’s largest city, Chicago.

On 9th November, voters decided to vote yes to a binding referendum that would merge the Office of the Cook County Recorder of Deeds with the Cook County Clerk’s office.

With the merging scheduled to happen no later than 2020, the office faces the difficult challenge of preparing for transfer the land deed library of the second-most populous county in the United States.

“Implementation of a blockchain-based system for processing transactions and conveying property would be a long-term goal, given that we are approaching the issue from a statewide focus (that it would make sense that all 102 counties in the state run ‘nodes’) and also understanding that a few large changes need to be made to Illinois' Conveyances Act to allow deeds to be ‘electronic data’ rather than paper documents, at least for the purposes of record-keeping,” John Mirkovic, deputy recorder for communications for the Cook County Recorder of Deeds, told CoinDesk.

He further explained:

“Making public records data-driven is a key step for blockchain record-keeping. Our office would like to see a system where all land records offices verify each other's transactions, while also providing full disaster recovery and backup.”

Making data available

One of the Cook County Recorder of Deeds’ short-term goals through the Internet Blockchain Initiative is to create a blockchain system that would aggregate all vacant and condemned property metadata into a “digital title” that would have a pointer from the existing online record.

The idea in doing this is to create a defense against scammers who are selling these properties to buyers seeking “fixer-uppers,” as current tax or home inspector data may not be available from a rudimentary deed check.

Successful implementation of this pilot program, which is currently in testing with Velox.re, could open the door for additional state-run public data blockchains.

“Testing the effectiveness of data-driven records processing for land titles, which are complicated transactions, would also as a by-product show that the State could use such a system to transfer vehicle titles, which are simple transactions usually tied to an already-existing unique identifier,” added Mirkovic.

“This could completely replace the state's paper-based car titling system, allow regulated auto-dealers to generate their own vehicle titles the day they come off the truck, and sell them right away (rather than sending in applications and waiting for reply),” he continued.

“Further, the Department of Insurance and private insurers could be incorporated into the vehicle titling system, meaning that law enforcement could know a vehicle's insurance coverage status before they even walk up to talk to the driver," Mirkovic said.

As Bryan Schneider, secretary of the Illinois Department of Financial and Professional Regulation, said in his comments at the Blockchain Conference Chicago, while the state will endeavor to make Illinois a welcoming place for cryptocurrency companies, the focus of the Illinois Blockchain Initiative is towards embracing the potential of blockchain technology openly and using it as a means to improve efficiency and transparency while making security, confidentiality and regulation factors that can be addressed in real time.

“We know that talk is cheap and action is where it counts, so you have the commitment of myself and the leaders up here with me to actually make things workable for technology companies and their customers that want to do business here in Illinois,” said Schneider.

Image via Shutterstock

GovernmentIllinois

Original author: Frederick Reese