TRUECHAIN: HIGHLY PERFORMANT DECENTRALIZED PUBLIC LEDGER FIRST DRAFT WORK IN PROGRESS arXiv:1805.01457v1 [cs.DC] 3 May 2018 ARCHIT SHARMA1 , JASPER L2 , ERIC ZHANG3 1 [email protected] 2 [email protected] 3 [email protected] A BSTRACT. In this paper we present the initial design of truechain consensus protocol and other technical details. Briefly, our consensus design enjoys the same consistency, liveness, transaction finality and security guarantee, a de-facto with the Hybrid Consensus. We discuss optimizations like frequency of rotating committee members and physical timestamp restrictions. We go on to propose the idea of a new virtual machine on top of Ethereum which adds permissioned-chain based transaction processing capabilities in a permissionless setting. We also use the idea of data sharding and speculative transactions, evaluation of running of smart contracts in a hybrid cloud infrastructure and usage of existing volunteer computing protocols for something we introduce as a compensation infrastructure. In the next version of this Yellow Paper, we will address some of these properties formally along with few of the future directions listed at the end of the paper. 1. I NTRODUCTION highly dependent on a few stakeholders to make the decisions on inclusion and exclusion of delegates. Moreover, there is With the surging popularity of cryptocurrencies, blockchain no transparency without Merkel trees and this type of system technology has caught attention from both industry and could always suffer from nothing-at-stake paradox. academia. One can think blockchain as a shared comput- In this Paper, we propose TrueChain, a Hybrid Protocol ing environment involving peers to join and quit freely, with which incorporates a modified form of PBFT (Practical Byzan- the premis for a commonly agreed consensus protocol. The tine Fault Tolerance) and POW (Proof of Work) consensus. decentralized nature of blockchain, together with transaction The POW consensus ensures incentivization and committee se- transparency, autonomy, immutability, are critical to crypocur- lection while the PBFT layer acts as a highly performant con- rencies, drawing the baseline for such systems. However sensus with capabilities like instant finality with high through- top earlier-designed cryptocurrencies, such as Bitcoin and put, transaction validation, rotating committee for fair trade Ethereum, have been widely recognised unscalable in economy and a compensation infrastructure to deal with non- terms of transaction rate and are not economically viable uniform infrastructure. The nature of hybrid protocol allows it as they require severe energy consumptions and computation to tolerate corruptions at a maximum of about one third of peer power. nodes. With the demand of apps and platforms using public blockchain growing in real world, a viable protocol that en- 2. BACKGROUND ables higher transaction rates is a main focus on new sys- tems. For example, consider a generic public chain that could The core strength of this proposal lies in the recognition of host computationally intensive peer to peer gaming applica- the theorems proposed in the Hybrid Protocol by Pass and tions with a very large user base. In such a chain, if it also Shi. We benefit from the fact that there is a lot of design space hosts smart contracts for Initial Coin Offerings in addition to for further optimizations in that paper. The use of DailyBFT as a Digital Advertisement applications, we could easily expect a committee members allows for the rotating committee feature huge delay in transaction confirmation times. which provides for better fairness for the consensus validating There are other models like delegated mechanism of Proof peers. of Stake and Permissioned Byzantine Fault Tolerant (BFT) The POW nodes could benefit from incentivization infras- protocols. The BFT protocol ensures safety as long as tructure while they are also a part of the slower snailchain, only one third of the actors in the system are intention- helping deploy smart contracts. ally/unintentionally malacious adversaries, at a time. This is a 2.1. Related Works. Hybrid Consensus follows a design par- really good mechanism, however a BFT chain alone has a prob- adigm where BFT and PoW are combined together so that it lem with scalability and pseudo-decentralization. The Proof enjoys best of both worlds. In general, Hybrid Consensus will of Stake protocol with a small number of validators could al- utilize BFT protocols, which by default works in a permis- though facilitate high throughput, but the system in itself is sioned setting where all the identities are known a priori, as Date: April 28th, 2018. 1
Truechain: Highly Performant Decentralized Public Ledger First Draft a fast path dealing with large amount of incoming transactions. initial comm distinct public keys. During this, a continuous While PoW protocols choose the BFT committee based on a “Until done” check happens and once completion of gossip combination of csize (number of blocks mined) and of stake in happens at each step, all the stop log entries are removed / stake out. This provides the barebone necessary to deal with Here is how the subprotocol works for when the node is not dynamic membership and committee switching in the permis- a BFT member:- On receival of a transaction, the message is sionless setting. added to history and signed by a third of the initial comm dis- tinct public keys 3. C ONSENSUS The signing algorithm tags each message for the inner BFT Our consensus design is largely based on Hybrid Consensus instance with the prefix 0, and each message for the outer Dai- by Pass and Shi , with several modifications and improve- lyBFT with the prefix 1 to avoid namespace collision. ments in order to tailor for the application scenarios that we 3.2.3. The mempool subprotocol. Initializes TXs with 0 and focus on. In this section we will assume the readers are famil- keeps a track of incoming transactions with a Union set. On iar with every detail of Hybrid Consensus protocol. receiving a propose call, it adds the transaction to log and com- 3.1. Design Overview. In this subsection we will present an munciates with gossip protocol. It also supports query method overview of our consensus protocol. In this protocol, we use to return confirmed transactions. By keeping track of transac- the same abstract symbols and definitions in . In the fol- tions in a set, it purges the ones already confirmed. lowing part of this section, we will explain our modifications 3.2.4. Main Hybrid Consensus protocol. A newly spawned and further constructions on top of Hybrid Consensus. node with an implicit message routing that carries with it Our adversary model follows the assumptions in  where history of the transcripts sent and received. This interacts adversaries are allowed to mildly adaptively corrupt any node, with the following components - Mempools, Snailchain, Pre- while corruptions do not take effect immediately. In the next process, Daily Offchain Consensus, and on chain validation. version of Yellow Paper we will formally explain our modifi- cations in Universal Composabililty model . 3.3. Variant Day Length and Hybrid Committee Election. Note that all the pseudocodes in this Yellow Paper are sim- In , BFT committee instances are switched after a fixed pe- plified for the sake of easy explanations. They are not opti- riod of time (with the snailchain as a logical clock). And new mized for engineering. committee is formed simply by the miners of the latest csize number of blocks inside snailchain. In our consensus design, 3.2. Recap of Hybrid Consensus Protocol. In this subsec- we want to exploit the intuition that, if the committee behaves tion, we recall major components and definitions from the Hy- well, we don’t have to force them to switch, and therefore the brid Consensus protocol. overhead of switching committee could be prevented in some 3.2.1. Fruitchains as opposed to Nakamoto chain. We follow situtations. On the other hand, this will raise difficulty for new the adoption of Fruitchain instead of Nakamoto (traditional nodes to get elected as a committee member if the previous chain) for the slowchain (snailchain), so as to defend against committee keeps good records. Therefore we still keep the de- 1/3 corruption (in hashpower) for a random small constant , to sign of forcibly switching the committee every fixed amount of obtain an optimal resilience. time, but with a much lower frequency, (for example, the com- mittee will be switched every K days). On the other hand, we 3.2.2. Daily offchain consensus protocol. In DailyBFT, com- incorporate the idea of authenticated complaints from Thun- mittee members run an offchain BFT instance to decide a daily derella  where the slowchain can be used as the evidence log, whereas non-members count signatures from committee of misbehaviour by BFT committee members. That is, when- members. It extends security to committee non-members and ever a committee misbehavior is detected from the snailchain, late-spawning nodes. It carries with it, a termination agree- the next day starting point (not necessarily the K -th day) will ment which requires that all honest nodes agree on the same trigger a forced switch. final log upon termination. In DailyBFT, committee members More over, we will replace the committee election criterion. output signed daily log hashes, which are then consumed by In Hybrid Consensus, committee members are chosen from the the Hybrid Consensus protocol. These signed daily log hashes miners of the most recent snailchain blocks. We decide to se- satisfy completeness and unforgeability. lect committee members based on a hybrid criterion by stakes On keygen, add public key to list of keys. On receiving a and randomness. To be more specific, we allow full nodes to comm signal, a conditional election of the node as committee propose special stakei n and stakeo ut transactions to temporar- member happens. The environment opens up the committee ily freeze their token assets. And whenever a committee switch selectively. happens, we will elect θ · csize accounts based on their frozen Here is how the subprotocol works for when the node is stakes where θ ∈ [0, 1] is a manual parameter. And following a BFT member:- A BFT virtual node is then forked. BFT the design of , we choose the rest (1 − θ) · csize nodes virtual node here, denoted by BFTp k, then starts receiving the based on the result of VRF  where the seed is determined TXs (transactions). The log completion is checked and stopped by the seed used in previous committee selection, as well as the iff the stop signal has been signed off by atleast a third of the proposed randomness from recent csize blocks. Different from
Truechain: Highly Performant Decentralized Public Ledger First Draft Algorand , here we don’t count stake weights for this part (2) The order within a batch of transactions output by the of selection. BFT committee is strictly ordered by timestamps. Notice that the nodes that is chosen by random functions (3) Nodes cannot manipulate fake physical timestamps will have a high probability of not being online. For this rea- because of the timing window restriction. son, given the estimated online rate ron , since we don’t want One obvious disadvantage of this modificaion will be the the offline nodes to take the Byzantine quota, we need to make f reduction in terms of throughput due to aborting transactions sure ron · θ < csize . Usually we take θ = 2ronfcsize . Another when the parameter T∆ is inappropriate for the varying net- potential design alternative is that we can allow offline nodes work latency. Another disadvantage is that, the BFT com- by design . mittee members are still allowed to lie about their local time Note that a party in charge of overwhelming computation and reject certain transactions. However, committee members resources will be likely to manipulate the input of VRF, but can reject certain transactions anyway. But honest nodes could that already goes beyond our security assumption. potentially reject ignorant transactions because of their unsyn- chronzied clocks. This issue can be reduced by adding restric- 3.4. Application Specific Design. Our consensus design is tions on the eligibilities of the BFT committee. Later we will aware of application specific requirements and tailors for them, see that to get into the committee, the nodes should present under the conditions that the consistency, liveness and security evidence of synchronized clocks. properties are not compromised. 3.5. Computation and Data Sharding, and Speculative 3.4.1. Physical Timing Restriction. Conventional consensus Transaction Execution. In this subsection we introduce our design by default allows miners / committee members / lead- sharding scheme. ers to re-order transactions within a small timing window. This An important modification over the original Hybrid Con- raises a problem for some decentralized applications such as sensus is that we add computation and data sharding support commercial exchanges where the trading fairness requires the for it. And even more, first of its kind, we design a speculative timing order between transactions to be carefully preserved, transaction processing system over shards. The idea is clear. or otherwise malicious (or, even normal rational) participants In Hybrid Consensus, the DailyBFT instances are indexed into will have the incentive to re-order transactions, or even insert a determininstic sequence DailyBFT[1 ... R]. We allow mul- its own transactions, to gain extra profits. And this incentive tiple sequences of DailyBFT instances to exist at the same will be magnified under high throughputs. time. To be precise, we denote the t-th DailyBFT sequence And what is even worse, is that such malicious re-ordering by shard St . For simplicity, we fix the number of shards as C . is impossible to distinguish because naturally network latency Each DailyBFT is a normal shard. Besides C normal shards, will cause re-ordering and such latencies can only be observed we have a primary shard Sp composed of csize nodes. The by the receiver itself and therefore it has the final evidence of job of the primary shard is to finalize the ordering of the out- numbers regarding network latency. put of normal shards as well as implementing the coordinator To support decentralized advertisement exchanges, we try in distributed transaction processing systems. And the normal to reduce such problems by incoporating one more restriction shards, instead of directly connecting with Hybrid Consensus called sticky timestamp. More specifically, with a heuristic component, submit logs to the primary shard, which in turn parameter T∆ , when proposing transactions, we require the talks to Hybrid Consensus. client to put a physical timestamp Tp inside the metadata of We don’t allow any two shards (either normal or primary) to the transaction, and this physical timestamp is signed together share common nodes, which can be enforced in the committee with the other parts of the transaction. Later when validators selection procedure. The election of multiple shards is similar inside BFT verify the transaction, it will do the following extra to the election procedure described in Section 3.3. checks as shown in Algorithm 1. We partition the state data (in terms of account range) uni- At the stage of materializing logs inside BFT, the leader formly into C shards. This will make sure that every query to will sort the transaction batch according to its physical times- the corresponding shard will return a consistent state. Since we tamps and break ties (though very unlikely) with the sequence are going to include meta data for each data unit, we split data number. Actually this step is not necessary because we can en- into units of data sectors and assign each data sector with an force the order later in the evaluation and verification. But for address. We have a mapping from data position to data sector simplicity, we put it here. address. For simplicity, from now on, we only discuss at the This set of modications give us several extra properties: level of data sectors. Each data sector DS[addr] has metadata (1) The order of transactions from any node Ni is in- of rts, wts, readers, writers. ternally preserved according to their physical times- We assume the partition principle is public and given the tamps. Thus the sequence order of these transactions address addr we can get its host shard by calling the function is strictly enforced. This will get rid of the possibility host(addr). of some malicious re-ordering that involves two tran- Notice that if we treat every normal shard (when the number scations from the same node. of adversaries is not large) as a distributed processing unit, we
Truechain: Highly Performant Decentralized Public Ledger First Draft Algorithm 1: Extra Verification Regarding Physcal Timestamp Data: Input Transaction TX Result: A Boolean value that indicates whether the verification is passed 1 current time ← Time.Now(); 2 if |current time − TX.Tp | > T∆ then 3 return false; // if the time skew is too large, reject TX . 4 var txn history = new static dictionary of lists; 5 if txn history[TX.from] == NULL then 6 txn history[TX.from] == [TX ]; 7 else 8 if txn history[TX.from][−1].Tp − TX.Tp > 0 then 9 return false; // To make sure the transactions from the same node preserve timing order. 10 else 11 txn history[TX.from].append(TX); 12 return true; F IGURE 1. Pseudo-Code for Extra Verification can incorporate the design of logical timestamps  in dis- 4. S MART C ONTRACTS IN V IRTUAL M ACHINES tributed transaction processing systems , which will em- 4.1. Design Rationale. Of all the reasons to have an power the processing of transactions. Here we utilized a sim- Ethereum Virtual Machine (EVM) , one of aims is to me- plified version of MaaT where we don’t do auto-adjustment of ter the usage with a transaction fee in a Proof of Work model. other transaction’s timestamps. Since ours is a hybrid model, we’ll take the liberty of explor- For normal shards, it acts exactly as described in DailyBFT ing this design space a little bit further. Let us consider the except the following changes to make it compatible for parallel possibility of a hybrid cloud ecosystem. speculative execution. A basic problem people have faced is the kind of crude For the primary shard, it collects output from all the normal mathematical notations followed in Ethereum’s Yellow Pa- shards. Notice that, the data dependency of transactions can be per . We therefore hope to follow something like KEVM easily inferred by their metadata. And a fact is that, if a trans- jellopaper  to list out the EVM and TVM (described action visits multiple remote shards, it will leave traces in all in 4.2) specifications. And in future, we hope to maintain the shards involved. When a normal shard submit logs to the our own specifications through Truechain’s github account primary shard, it will also write to the snailchain. (https://github.com/truechain). When the primary shard receives (or fetchs from the snailchain) a batch of txns from a shard, it will check if it 4.1.1. What about containers instead of VMs? One of the has received from all the shards transactions within this batch. blockchain frameworks out there that come as close to this If after certain timeout it has not received transactions from a idea as possible, is Hyperledger’s Fabric framework . If one particular batch, it means that batch has failed. In this case, sets out to convert Fabric’s permissioned nature into permis- a whole committee switch will be triggered at the next day sionless, one of the foremost challenges would be to solve the starting point. After receiving all the shards’ logs, the primary chaincode issue. What this means is while it’s possible to keep shard sorts the transactions based on their commit timestamps a chaincode/smart contract in a single container, that is not a (if some transaction has earlier batch number, it will be con- scalable model for a public chain. Having such a model for sidered as the first key in the sorting, however, if its physical public chain means having to run several thousand containers, timestamp violates the timestamps from many shards, we de- per se, several thousand smart contracts on a single node (be- cide that batch as invalid and all the transactions inside that cause each node maintains a copy). batch are aborted). After sorting, the primary shard filters all There have been attempts from the community on being the transactions and keeps a longest non-decreasing sequence able to run a certain maximum containers per node. The limit in terms of physical timestamps. Out the log to the Hybrid currently is 100 pods per node, per se, approximately 250 con- Consensus component as that day’s log. tainers per node, as illustrated in Kubernetes container orches- There are still many optimisation spaces. One certain con tration platform  and Red Hat’s Openshift Container Plat- is that the confirmation time in this design is not instant. form 3.9’s Cluster Limits . Even with latest storage tech- niques like brick multiplexing , the max possible value (say
Truechain: Highly Performant Decentralized Public Ledger First Draft Algorithm 2: Sharding and Speculative Transaction Processing 1 On BecomeShard: 2 Initialize all the state data sectors: lastReaderTS = −1, lastWriterTS = −1, readers = , writers =  3 With transaction TX on shard Si : 4 On Initialization: 5 TX.lowerBound = 0; 6 TX.upperBound = +∞; 7 TX.state = RUNNING; 8 TX.before = ; 9 TX.after = ; 10 TX.ID = rand; 11 On Read Address(addr): 12 if host(addr) == Si then 13 Send readRemote(addr) to itself; 14 else 15 Broadcast readRemote(addr, TX.id) to host(addr); 16 Async wait for 2f + 1 valid signed replies within timeout To ; 17 Abort TX when the timeout ticks; 18 Let val, wts, IDs be the majority reply; 19 TX.before.append(IDs); 20 TX.lowerBound = max(TX.lowerBound, wts); 21 return val; 22 On Write Address(addr): 23 if host(addr) == Si then 24 Send writeRemote(addr) to itself; 25 else 26 Broadcast writeRemote(addr, TX.id) to host(addr); 27 Async wait for 2f + 1 valid signed replies within timeout To ; 28 Abort TX when the timeout ticks. 29 Let rts, IDs be the majority reply; 30 TX.after.append(IDs) TX.lowerBound = max(TX.lowerBound, rts); 31 return; 32 On Finish Execution: for every TX′ inTX .before do 33 TX.lowerBound = max(TX.lowerBound, TX’.upperBound); 34 for every TX′ inTX .after do 35 TX.upperBound = min(TX.upperBound, TX’.lowerBound); 36 if TX.lowerBound ¿ TX.upperBound then 37 Abort TX; 38 Broadcast Precommit(TX .ID, ⌊ TX .lowerBound+TX 2 .upperBound ⌋) to all the previous remote shards which TX has accessed; // If TX.upperBound = ∞, we can set an arbitrary number larger than TX .lowerBound. 39 On receive readRemote(addr, ID): 40 if host(addr) == Si then 41 DS[addr].readers.append(ID); 42 return DS[addr].value, DS[addr].wts, DS[addr].writers; 43 else 44 Ignore 45 On receive writeRemote(addr, ID): 46 if host(addr) == Si then 47 DS[addr].writers.append(ID); 48 Write to a local copy; 49 return DS[addr].rts, DS[addr].readers; 50 else 51 Ignore F IGURE 2. Pseudo-Code for Sharding and Speculative Transaction Processing
Truechain: Highly Performant Decentralized Public Ledger First Draft Algorithm 3: Sharding and Speculative Transaction Processing (cont.) 1 On receive Precommit(ID, cts): 2 Look up TX by ID; 3 if Found and cts not in [TX.lowerBound, TX.upperBound] then 4 Broadcast Abort(ID) to the sender’s shard.; 5 TX.lowerBound = TX.upperBound = cts; 6 For every data sector DS[addr ] TX reads, set DS[addr ].rts = max(DS[addr ].rts, cts); 7 For every data sector DS[addr ] TX writes, set DS[addr ].wts = max(DS[addr ].wts, cts); 8 Broadcast Commit(ID, batchCounter ) to the sender’s shard.; // batchCounter is a number which increases by 1 whenever the shard submit a batch of log to the primary shard. 9 On receive 2f + 1 Commit(ID, batchCounter) from each remote shards which TX has accessed: 10 TX.lowerBound = TX.upperBound = cts; 11 For every data sector DS[addr ] TX reads, set DS[addr ].rts = max(DS[addr ].rts, cts); 12 For every data sector DS[addr ] TX writes, set DS[addr ].wts = max(DS[addr ].wts, cts); 13 Mark TX committed; 14 Let TX .metadata = [ShardID, batchCounter ]; 15 On output log 16 Sort TX ’s based on their cts. Break ties by physical timestamp. MAX CONTR) of containers could not possibly reach (at least (EVM) , which tries to follow total determinism, is com- right now) 1000. This issue could further be looked up in pletely optimized and is as simple as it gets, to make incen- the discussions on kubernetes issues github page  around tivization simple step to calculate. It also supports various fea- workload-specific limits that usually determine the maximum tures like off-stack storage of memory, contract delegation and pods per node. People who wish to scale containers usually inter-invocation value storage. prefer horizontal scaling rather than a vertical scaleup [2, 6], We would reuse the EVM specifications for the snailchain, as the latter significantly increases complexity of design deci- but add a new specification for TVM in the next version of this sions. And there’s no one-size-fits-them-all rule for a cluster Yellow Paper, after careful consideration of the design ratio- scale configuration as that entirely depends on the workload, nale similar to EVM, deriving the stack based architecture uti- which being more in our case due to its decentralized nature, lizing the Keccak-256 hashing technique and the Elliptic-curve isn’t very convincing for taking a step towards scaling this. At cryptography (ECC) approach. this point, it becomes more of an innovation problem than a The Truechain infrastructure will utilize a combination of simple technical specification search. Ethereum currently has EVM and another EVM-like bytecode execution platform for > 1000 smart contracts deployed. Therefore this would be launching smart contracts. We choose to use one VM for POW nothing but a crude attempt at optimizing the container ecosys- and another for PBFT, embedded within each full node, so they tem’s design space. could manage invocation calls on per-need basis. Now let us expand a bit on the container scenario. Given The TVM backs the DailyBFT powered chains, which in- the above crisis, a possible solution is to use container in a teract with the following components: serverless architecture. But consider a scenario where > 2000 contracts are online and the concurrent requests, i.e., invoca- • re-using some of the concepts from tendermint, like tion calls to chaincode (a moving window) at a time exceed the ABCI (Application BlockChain Interface) which MAX CONTR value, we then face the same problem all over offers an abstraction level as means to enable a con- again. Therefore, it is only advisable to add a throttling rate sensus engine running in one process to manage an limit on the max concurrent requests. This severly limits the application state running in another. Transactions Per Second from the consensus, by design. Engi- • A different consensus engine pertaining to dailyBFT neering should not be a bottleneck to what could be achievable chians, alternatively. Therefore, we choose to stick to EVM design, • A permissioned Ethereum Virtual Machine although a bit modified for our purpose. • An RPC gateway, which guarantees (in a partially asynchronous network) transaction finality #TODO - formally define transition states of TVM, smart 4.2. Truechain Virtual Machine (TVM). A typical example contracts deployment strategy and a way to deploy permis- in this space would be that of the Ethereum Virtual Machine sioned VM onto a permissionless chain.
Truechain: Highly Performant Decentralized Public Ledger First Draft #TODO - define parameter to switch between the POW and • Detailed incentivization techniques for compensation the full node (POW and PBFT). infrastructure, so heavy infrastructure investors don’t suffer from ’left-out’, ’at a loss’ problem 5. B LOCKS , S TATE AND T RANSACTIONS • Sharding techniques with replica creation to minimize # TODO - Talk about changes to blocks, world state flow, the transaction set rejection from the BFT committee. transactions and execution model • Addition of zero knowledge proof techniques for pri- vacy. 6. C HANGES TO THE E THEREUM B LOCKCHAIN PARADIGM • Hybrid infrastructure of EVM, TVM and Linux con- tainer ecosystem. #TODO - Talk about the genesis block • Sections for Virtual Machine Specification, Binary 6.1. Incentive Design. #TODO - talk about incentive design Data Encoding Method, Signing Transactions, Fee Schedule and Ethash Alternative. 6.2. Compensation Infrastructure. In this section we will present a concept of compensation infrastructure in order to balance the workload of BFT committee members and non- member full nodes. Treating all shards as equivalent of each other in terms of 8. C ONCLUSIONS network and CPU bandwidth could produce skewed results, with inconsistent TPS, or worse, sometimes cross timeout lim- We have formally defined Hybrid Consensus protocol and its, while ordering of transaction takes place from the Primary its implementation along with plausible speculations in the shard. To tackle this, we propose a compensation infrastruc- original proposal. In this draft, we have introduced various ture, that works along the lines of Berkeley Open Infrastructure new concepts some of which we will detail in the next version for Network Computing. There has been a previous attempt in very soon. We recommend people to choose ASIC resistant this area from Gridcoin  and Golem network . hardware for deployment of the POW only versus full nodes, Gridcoin’s distributed processing model relies pre- although more details on hardware shall follow soon. approved frameworks to the like of Berkeley Open Infras- • A permissioned BFT chain that runs on a few nodes tructure for Network Computing (BOINC) , an opensource in the permissionless POW based network. distributed volunteer computing infrastructure, heavily utilized • The BFT committee is a rotating one, preventing cor- within cernVM in turn, harnessed by the [email protected] ruption in a timely manner project  A framework like this has to tackle non-uniform • The BFT committee is responsible for transaction val- wealth distribution over time. On the other hand, Golem is idation, and the POW nodes are only responsible for another great ongoing project with concrete incentivization choosing/electing the committee manners according scheme, which would be used as an inspiration for compensa- to some rules we’ve derived and re-defined. tion infrastructure’s incentivization methodology. However a • The new permissioned VM, we’ve surmised, could be keeping in mind, a widely known problem is that a blockchain inspired from the EVM, but with different block states powered volunteer computing based rewarding model could and transaction execution flows easily fall prey to interest inflation if the design lacks a de- • The contemporary permissionless EVM in the POW cent incentive distribution scheme over time. So to speak, an chain co-exists with this new permissioned VM increasing gap between initial stake holders minting interest (which we call Truechain Virtual Machine - TVM) due to beginner’s luck (algorithmic luck) and the contributors • The TVM would be the one to validate any transac- joining late, could thence be found fighting for rewards from tions related to consensus, while the traditional EVM smaller compensation pools that further condense. would need to be re-worked to not really mine for con- Depending on the kinds of transactions and whether we’d sensus, but for election of BFT using Variable Day need decentralized storage for some of the smart contracts, we length puzzle. propose the use of a hybrid infrastructure that utilizes BOINC • The incentivation model needs to be re-worked such and IPFS/Swarm, along side of EVM and TVM. This would that it is based off of TVM, and we still reward the make use of Linux Containers to deal with isolation of re- miners in POW chain. sources and we hope to expand on this section in the next ver- • We would eventually support sharding for the BFT sion of this yellowpaper. committee nodes, for scalability. 7. F UTURE D IRECTION • A compensation infrastructure, which accounts for node configuration non-uniformity (different Even after optimizations to the original Hybrid Consensus, CPU/memory/network bandwidth in the node pool), we acknowledge various optimizations possible on top of what would eventually be a part of the consensus, thus was proposed in this paper. There are following possibilities: speeding up transactions. • Improving timestamp synchronization for all nodes, • The smart contracts execution would thus only happen with no dependency on centralized NTP servers. in TVM (BFT node).
Truechain: Highly Performant Decentralized Public Ledger First Draft 9. ACKNOWLEDGEMENTS  E. Androulaki, A. Barger, and V. e. a. Bortnikov. Hyperledger fab- ric: A distributed operating system for permissioned blockchains. URL We owe a great deal of appreciation and are thankful, to https://arxiv.org/pdf/1801.10228v1.pdf, 2018. the following folks for their untiring work towards pushing the  J. Blomer, L. Franco, A. Harutyunian, P. Mato, Y. Yao, C. Aguado Sanchez, and P. Buncic. Cernvm a virtual software appliance for lhc protocols for a decentralized sovereignty, for their design ra- applications. URL http://iopscience.iop.org/article/10.1088/1742- tionale and implementations which served as a solid reference 6596/219/4/042003/pdf, 2017.  V. Buterin. Ethereum white paper, 2014. URL architecture in our proposal above. These folks and their lega- https://github.com/ethereum/wiki/wiki/White-Paper. cies are as mentioned below:  R. Canetti. Universally composable security: A new paradigm for crypto- graphic protocols. In Foundations of Computer Science, 2001. Proceedings. • Rafael Pass, Miguel Castro, Satoshi Nakamoto, Vi- 42nd IEEE Symposium on, pages 136–145. IEEE, 2001. talik Buterin, Gavin Wood, Ethan Buchman, An-  M. Castro, B. Liskov, et al. Practical byzantine fault tolerance. In OSDI, drew Miller et al for their untiring work, contribu- volume 99, pages 173–186, 1999.  Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich. Algorand: tions and continuous improvisations while spearhead- Scaling byzantine agreements for cryptocurrencies. In Proceedings of the ing the glamorous Improvement Proposals forums in 26th Symposium on Operating Systems Principles, pages 51–68. ACM, 2017. addition to the active participation through Reddit,  E. Hildenbrandt, M. Saxena, and X. e. a. Zhu. Kevm: A Mailing lists, chat forums, white and Yellow Papers, complete semantics of the ethereum virtual machine. URL and rest of the mediums alike. https://www.ideals.illinois.edu/handle/2142/97207, 2017.  D. e. a. Lombraa Gonzlez. Lhchome: a volunteer computing system for • CNCF and Kubernetes communities for their inspir- massive numerical simulations of beam dynamics and high energy physics ing ventures into hybrid cloud computing. events. URL http://inspirehep.net/record/1125350/.  H. A. Mahmoud, V. Arora, F. Nawab, D. Agrawal, and A. El Abbadi. Maat: R EFERENCES Effective and scalable coordination of distributed transactions in the cloud. Proceedings of the VLDB Endowment, 7(5):329–340, 2014.  Container-native storage for the openshift masses. URL  S. Micali, M. Rabin, and S. Vadhan. Verifiable random functions. In Foun- https://redhatstorage.redhat.com/2017/10/05/container-native-storage- dations of Computer Science, 1999. 40th Annual Symposium on, pages 120– for-the-openshift-masses/. 130. IEEE, 1999.  Deploying 2048 openshift nodes on the cncf cluster. URL  S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. URL https://blog.openshift.com/deploying-2048-openshift-nodes-cncf-cluster/. http://bitcoin.org/bitcoin.pdf, 2008.  Gridcoin whitepaper: The computation power of a  R. Pass and E. Shi. Hybrid consensus: Efficient consensus in the permis- blockchain driving science and data analysis. URL sionless model. In LIPIcs-Leibniz International Proceedings in Informatics, https://www.gridcoin.us/assets/img/whitepaper.pdf. volume 91. Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2017.  Increase maximum pods per node [kubernetes github issue #23349]. URL  R. Pass and E. Shi. The sleepy model of consensus. In International Con- https://github.com/kubernetes/kubernetes/issues/23349. ference on the Theory and Application of Cryptology and Information Se-  Kubernetes: Building large clusters. URL curity, pages 380–409. Springer, 2017. https://kubernetes.io/docs/admin/cluster-large/.  R. Pass and E. Shi. Thunderella: blockchains with optimistic instant confir-  Kubernetes scaling and performance goals. URL mation, 2017. https://github.com/kubernetes/community/blob/master/sig-  T. G. team. The golem project: The golem project. URL scalability/goals.md. https://golem.network/doc/Golemwhitepaper.pdf, 2016.  Red hat openshift container platform’s clus-  G. Wood. Ethereum: A secure decentralized generalized transaction ledger. ter limits. URL https://docs.openshift.com/container- URL https://ethereum.github.io/yellowpaper/paper.pdf, 2018. platform/3.9/scaling performance/cluster limits.html.  X. Yu, A. Pavlo, D. Sanchez, and S. Devadas. Tictoc: Time traveling opti-  D. P. Anderson. Boinc: A system for public-resource computing and stor- mistic concurrency control. In Proceedings of the 2016 International Con- age. URL https://boinc.berkeley.edu/grid paper 04.pdf. ference on Management of Data, pages 1629–1642. ACM, 2016. A PPENDIX A. T ERMINOLOGY TrueChain Virtual Machine (TVM): In contrast to EVM which does handles incentivization and rotating committee selec- tion, a TVM is based on similar design principles but carries out actual consensus and voting based off of PBFT based Hybrid Consensus.