Federated Consensus | Table O Contents

Federated consensus is a protocol for running a single blockchain across a Permissioned Blockchain Network …

• Federated Consensus | Table O Contents
  • Permissioned Blockchain Network (PBN)
    • PBN Benefits
    • Logic
  • Block Generator
    • The Quorum
  • Multiple Generators
    • Liveliness
    • Future Consensus
  • Forking the Chain
    • The Power of Zero
    • Limit
  • Last Subtitle
  • Support
    • Patreon

Note. The Flammarion Logo Badge in the page header above is an .svg image file set to the dimensions of 5% width, auto height, and zoom. Go ahead and test the zoom-out feature by hovering over the badge to engage the expansion of the image.

Permissioned Blockchain Network (PBN)

Hint. Traditional blockchain mining for BTC or ETH costs exponentially greater amounts of electricity every month as Bitcoin and Ethereum expand their networks and platforms.

When operating a Federated Consensus blockchain model over a Permissioned Blockchain Network, or PBN …

• A number of advantages and new features emerge

• In addition to the original base reasons for creating a genesis block in the first place

Which begs the question, “Why we are still allowing Bitcoin and Ethereum to move counter to our Anti-fossil fuel regiments by consuming copious amounts of “should never be allowed to expand” hydro generated cheap electricity from the East?”

PBN Benefits

1. A Permissioned Blockchain Network ( like the protocol of “Proof O Work” that underpins both Bitcoin and the Ethereum networks ) prevents the double-spending of assets across the subject network

2. A Permissioned Blockchain Network ( also like the protocol of “Proof O Work” that underpins both Bitcoin and the Ethereum networks ) prevents history from being edited or rewritten across the subject network

3. A Permissioned Blockchain Network reduces leakage

4. A Permissioned Blockchain Network ( un-like the protocol of “Proof O Work” that underpins both Bitcoin and the Ethereum networks ) runs on “free” gas.

5. A Permissioned Blockchain Network works very fast. Think along the lines of Bitcoin or Ethereum and the wait-time required ( two-to-ten minutes … maybe! ) to confirm a transaction in either the (BTC) or (ETH) blockchains. Not very conducive to IoT, or Internet of Things transactions. Whereas a PBN can stamp a block-o-transactions in seconds.

Logic

A set of designated conditions must be met before a block can be written to the chain under a Federated Consensus protocol.

Specifically, a quorum of block signers must digitally sign off before a block can be considered “accepted”.

A set of pre-specified public keys can be used to validate the incoming signatures.

Block Generator

A Block Generator filters incoming traffic for invalid transactions.

Periodically, as set by the programming team, the Block Generator can also be charged with the duty of aggregating blocks of incoming transactions.

Once a block has been filled to its limit of (10) transactions, or if a designated number of Unix micro-seconds have past ( approximately 250 seconds ), the Block Generator sends the block of transactions to the quorum of block signers for an “Authority to Forge”.

The Quorum

For each member of the quorum of block signers, the incoming block is checked for the following list of attributes:

• Was the block generated by the assigned Block Generator?

• Did the Block Generator sign the block?

• Is the block valid?

• Is the Unix time stamp within (50) seconds of the current network time?

• Does the block contain an acceptable future consensus program for authenticating the next block?

In the event the block passes this round of checks, then the Block Signer adds his or her public key to the block as proof of digital signature.

Note. The most previous forged block will have a consensus program that was installed at the time of formation for authenticating this, the next block.

One of the features of the previously installed consensus program is a designation of exactly how many signatures are required to establish a quorum.

When the Block Generator receives back the required number of public keys, the keys tendered are matched against the published set of authorized signers.

If one or more of the public keys returned do not match the published set of authorized signers, then the block cannot be forged.

If on the other hand, the public keys returned do match the published set, and the number of keys returned does match the minimum number of keys designated to establish a quorum, then the block is forged by the Block Generator and added to the blockchain of the network.

Remember, the blockchain is the backbone of the network platform from which all data generated by the underlying transactions remains immutable once forged, and from which all data may be reconciled or extracted for proof of payment, for aggregating taxes due, and for regulating quantity.

Multiple Generators

Although the mechanism for operating the generator can indeed function in a case of one, multiple generators working on a “Proof-O-Shift” protocol in round robin may send forgable blocks to a subset M = (5) of N = (25) for signature at random.

All twenty-five (25) of the N set of authorized signers must vote on the viability of each block with their public keys in groups of five (5) selected randomly at the time of the “Proof-O-Shift” Block Generator requests the forging of a block.

For example, as a list of ten (10) Block Generators progress through their stack bundling transactions and executing forge requests to which set of five (5) authorized signers they know not, the pool of authorized signers at the same Unix time stamp are unaware who will be their co-authorized signers, even though which Block Generator may be known by perusing the shift schedule at that mark.

Liveliness

Where the variable (A) represents the number of valid signatures returned from the (M) subset of five (5) authorized signers presented out of a total (N) population of authorized signers, if three (3) (A) of five (5) (M) return safely, then the block may be forged.

Future Consensus

At the block level, at the time of forge, the assigned Block Generator injects a future consensus program into the instant block to be used by the next block in the chain for verification purposes.

Although the Block Generator when engaged in the process of forging of a new block may inject the same blanket block level future consensus program as used on previously forged blocks, the underlying block level future consensus program injected may be changed incrementally.

Forking the Chain

Attempts to fork the chain nefariously can be met by the formula: 2(A) - (M) - 1 ≧ ฿; where a test of the result of the formula ( is or is not greater than or equal to ) must prove the boolean true before a block can be forged to the chain; where ฿ ( the Thai bhat symbol, or pipe B ) represents the number of bad signatures returned.

In our above example, the test would prove the boolean true because two (2) times (A); where the number of accepted (A) signatures received back is equal to five (5), or ten (10) … Less the number of signature requests made (M); where (M) is equal to five (5), or five (5) … Less one (1) is equal to four (4), is greater than or equal to zero(0).

Conclusion. Because the result zero (0) is greater than or equal to the number of bad (฿) signatures returned; where (฿) is equal to zero (0), the block may progress to the forging stage.

The Power of Zero

Altering the number of bad (฿) signatures returned from zero(0) to two (2) in our above example grants us an “over the limit”, all other variables remaining the same.

The result of the boolean test, given (฿) = two (2), would prove the boolean false because two (2) times (A); where the number of accepted (A) signatures received back is equal to three (3), or six (6) … Less the number of signature requests made (M); where (M) is still equal to five (5), or one (1) … Less one (1) is equal to zero (0), is not greater than or equal to two(2).

Conclusion. Because the result zero (0) is not greater than or equal to the number of bad (฿) signatures returned; where (฿) is equal to two (2), the block may NOT progress to the forging stage.

Limit

Altering the number of bad (฿) signatures returned from zero(0) to one (1) in our above example grants us our “limit”, all other variables remaining the same.

The result of the boolean test, given (฿) = one (1), would prove the boolean true because two (2) times (A); where the number of accepted (A) signatures received back is equal to four (4), or eight (8) … Less the number of signature requests made (M); where (M) is still equal to five (5), or three (3) … Less one (1) is equal to two (2), is greater than or equal to one (1).

Conclusion. Because the result two (2) is greater than or equal to the number of bad (฿) signatures returned; where (฿) is equal to one (1), the block may progress to the forging stage.

Last Subtitle

More to come …

Note. The above synopsis was derived from an article written by the Chain [2].

1. The CHAIN is an acronym for the Chain Virtual Machine and its accompanying Ivy programming language. Published by © 2017 Chain.com.

Support

Please support the co-workers who aggregate the Source Links for our projects.

Patreon

Like what you see in this project? If so, then support the authors and machine-elves who aggregate the source links and pages for our projects via Patreon.