The final season of Game of Thrones is currently airing. The long anticipated conclusion to the epic battle over The Iron Throne — rule over the Seven Kingdoms of Westeros.

Consider the “final episode” (don’t worry, this is all made up, no spoilers here): The last battle is upon us; The northern armies led by the Starks approach the battlefield; the armies of Daenerys are there too; and so are the Lannister armies, led by Cersei. John Snow, ever the responsible adult, proposes an alternative: “Instead of bloodshed, why don’t we just have a democratic election?” Everybody nods in agreement. The soldiers cheer. Credits.

Cersei volunteers to run the elections. House Lannister places voting booths in all reaches of Westeros and every citizen in the Seven Kingdoms writes their desired ruler’s name on a ballot. The ballots are then all shipped to King’s Landing where Cersei counts the votes and announces the winner.

The process goes through and Cersei is excited to announce that she won. Would you trust these elections?

As it turns out, not all democracies are equal. If you’re interested to see the leaderboard, check out how every country ranks at the 2018 Democracy Index.

Most of the countries in the list, notably those with the low ranking in red, openly pride themselves as being democratic and celebrate periodic elections where the populous get a chance to choose their leaders. But evidently, some democratic processes are prone to manipulation allowing existing leaders to maintain their positions of power regardless of where the populous tries to shift it.

Pseudo-democracies are not the only ones with problems. There are issues with the top 15% in the list. Take a look at the US for example, number 25 in the list and the historical epitome of modern democracy (no cynicism intended). “Gerrymandering” is one example of a US problem where the political party in power can draw lines between voting districts that are favorable to itself.

Democracies are complicated to implement, the nuances are plenty. And through their analysis and criticism, we have the chance to improve on them. To design processes that better guarantee their purity and withstand corruption.

Proof-of-Stake systems behave in a very similar way. Voting, or the degree of influence, is based on ownership of stake instead of citizenship, but otherwise, the process is prone to similar nuances and must be designed to withstand manipulation. We must also continuously criticize PoS implementations so we have the chance to improve them.

And surely — there is plenty of criticism of PoS in the crypto world. The spectrum ranges from belief that the problems of PoS are solvable, debating the pros and cons of various implementations, to outright skepticism whether PoS can work at all.

Take for example the views of Joseph Lubin, co-founder of Ethereum and founder of ConsenSys, from the recent Deconomy: “How about EOS? As has been debated endlessly, a platform controlled by 21 crypto bros is just not all that decentralized. They can collude and censor if they wish. Governments and other well resourced actor can bribe them or force them to act against their will and against the well being and the security of the people using the platform”.

Let’s try to analyze Lubin’s argument why EOS, the dominant PoS implementation to date, is flawed. The 21 elected nodes of EOS “can collude and censor if they wish.” But what would happen if these nodes indeed collude against the interests of the entire network? If the effects aren’t minor, like a decline in token price, stakeholders will spring to action and just replace the colluding nodes. Elections on EOS rely on stake of the entirety of the network, and the majority of stake is assumed to be honest. So where’s the risk?

The risk is only if the colluding nodes could prevent their own replacement. The core of the matter, in my opinion, is that they are the ones running the elections. They are the ones counting the votes.

This isn’t all that different from Cersei counting the Westeros votes by herself.

The majority of PoS implementations are closed systems. The voting process is part of the protocol and the protocol is executed by nodes running the network, that are chosen according to the protocol. There is an essence of circular trust here.

What about Proof-of-Work algorithms? Is PoW prone to the same circular trust weakness?

Not really. Albeit its shortcomings in terms of efficiency and cost, PoW has several wonderful properties making it an excellent choice for decentralized trust. The primary of which is strong objectivity.

Objectivity (I’m using Vitalik’s definition here) means that a new node coming onto the network with no knowledge except (i) the protocol definition and (ii) the set of all blocks and other “important” messages that have been published can independently come to the exact same conclusion as the rest of the network on the current state.

What does this mean? Let’s say I’m an observer of the network and I want to be convinced that the state presented by the nodes in the network is indeed the “correct” one. Am I able to verify everything all by myself?

I can easily verify the amount of work in PoW by myself (that’s the point, hashes are easy to verify but hard to produce). And since PoW algorithms work according to the longest chain rule, I can objectively know which competing portrayals of the state (competing forks) is the right one.

You can say, in a sense, that the work itself is external to the system, and since the system is not closed anymore and does not vouch for itself using itself only, it becomes very trustworthy.

The objectivity property is unique to PoW (and similar methods like VDFs) but missing from most PoS implementations, leading to the circular trust weakness of a closed system.

Why is the lack of objectivity painful in PoS networks? The core offering of these networks is trust. As clients of the network, we should be able to verify the correctness of the relevant state and transactions. Verifying the correctness of data requires knowledge of the elected validators, since they are the ones allowed to sign blocks. In order to verify the elected validators, one can attempt to verify the election calculations. However, the calculations and the votes reside on the chain itself, signed by the same validators that we’re trying to verify in the first place. This cyclic dependency prevents the client from objectively verifying the correctness of their data. There are workarounds like trusting one of the validators, but these solutions are suboptimal. When our core offering is trust, we should hold ourselves to a higher standard.

If we could add objectivity to PoS, this will provide us with the missing external oversight — and give us a PoS implementation that is much more trustworthy. This will also give a pretty good answer to Lubin’s fears that the elected nodes in the system can collude and censor (particularly regarding the voting process that elects them).

So, is it possible to use PoW for this purpose without affecting the efficiency of PoS? There is a straightforward way to do this and it’s actually pretty simple. All you have to do is store the votes externally — preferably on a different decentralized network that is based on PoW.

Going back to our Westeros example, this would mean that the voting booths where the ballots are stored, will no longer be under Lannister control. The voting booths will be controlled by somebody else (external to the Game of Thrones universe) that will guarantee the sanctity of the elections. Once the elections have been made, whichever king is elected, is free to rule inside Westeros without external involvement.

The last part is important. If we are to maintain the efficiency of PoS, the rest of the network operation — mainly executing smart contracts on the PoS network, storing the state under consensus, doing everything a blockchain does — must not rely on PoW anymore. The only thing PoW will provide is an external guarantee of objectivity that will let any observer confirm that the PoS network is not colluding and has indeed been purely elected.

This is how this approach is different from layer 2 solutions. Second layers delegate all security and trust to the base layer. The base layer can overturn smart contract results, for example, or override state modifications made by the second layer. Our approach will still make the PoS system retain its own security and trust and thus hold value of its own.

So how would that work in practice?

The natural choice for a PoW network to store election votes is Ethereum. It is popular and obviously secure enough (in terms of hash power) as a standard of trust to be sufficiently disconnected incentives-wise from our own PoS network; and its smart contracts offer the flexibility for a proper integration.

If storing election votes on Ethereum is a simple solution, why don’t we see more PoS blockchains taking this approach?

One reason may be ego. Many PoS systems position themselves as potential “Ethereum-killers” — the scalable place to run apps until Ethereum reaches its own scalability milestones. Elections are also a crucial part of your solution, and using somebody else for a crucial part may “leak” some of your own perceived value to this somebody. We don’t share these views at Orbs. We see enormous value in existing ecosystems that have already been built. Not everything has to be replaced. We attempt to use existing infrastructures where they show advantage in order to make our own solution better.

Another reason this approach is difficult for many PoS blockchains is the utility of the token used for staking. Most PoS systems rely on the token for settlement related to the main purpose of these platforms — running apps. In other words, app developers use the token to pay nodes for running their apps.

Performing staking on Ethereum will also mean the utility of payment for app execution will have to be done on Ethereum as well. Since most PoS systems rely on a per-transaction gas model and aim for very high transaction throughputs, this would make Ethereum fees (in Ether) extremely high and inefficient — and thus miss the whole point of the efficiency of PoS.

This is another place where the Orbs architecture comes to our advantage. We’ve made a product decision long ago (see the original Position Paper) to have apps pay monthly subscription fees to Orbs nodes for executing their apps, instead of a per-transaction gas model. This product decision brings multiple benefits crucial for a pragmatic app execution platform such as predictable fees and the ability for apps to subsidize their users’ fees to encourage adoption (the same way Facebook subsidizes your Messenger costs and doesn’t charge you for their infrastructure fees per sending each chat message). This is part of our strategy to bring the AWS product experience to app developers in blockchain.

Apps on Orbs run on virtual chains that have dedicated and isolated resources. Subscriptions for resource dedication in virtual chains are paid monthly (or even longer if you want to guarantee future data availability). Making the payment once a month on Ethereum means Ether fees are negligible. There will be no impact on the efficiency of PoS.

The Orbs network is a PoS-based blockchain. It relies on the ORBS token which is used for paying infrastructure fees for running apps and also for staking and electing validators. The voting process is performed on Ethereum and thus ORBS is an ERC20 token.

Orbs is not a layer 2 for Ethereum though. Orbs does not delegate security and trust to Ethereum and holds its own value in its permissionless validator pool based on the PoS ecosystem of the ORBS token and its incentives model. Ethereum provides an external objective guarantee that any observer can verify that elected nodes on Orbs are indeed the ones the stakeholders voted for. For this important governance function, Ethereum is a crucial component in the Orbs design.

Apps running on Orbs are not executed on Ethereum, allowing them to fully enjoy the efficiency and decentralization in PoS, extremely low operation fees, extremely high scale and many other Orbs-specific benefits such as governance isolation, smart contracts in any language and more.

Learn more about Orbs here.

Originally published at https://www.orbs.com on May 2, 2019.

Why Proof-Of-Stake Systems Can Benefit From External Oversight was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The final season of Game of Thrones is currently airing. The long anticipated conclusion to the epic battle over The Iron Throne — rule over the Seven Kingdoms of Westeros.

Consider the “final episode” (don’t worry, this is all made up, no spoilers here): The last battle is upon us; The northern armies led by the Starks approach the battlefield; the armies of Daenerys are there too; and so are the Lannister armies, led by Cersei. John Snow, ever the responsible adult, proposes an alternative: “Instead of bloodshed, why don’t we just have a democratic election?” Everybody nods in agreement. The soldiers cheer. Credits.

Cersei volunteers to run the elections. House Lannister places voting booths in all reaches of Westeros and every citizen in the Seven Kingdoms writes their desired ruler’s name on a ballot. The ballots are then all shipped to King’s Landing where Cersei counts the votes and announces the winner.

The process goes through and Cersei is excited to announce that she won. Would you trust these elections?

As it turns out, not all democracies are equal. If you’re interested to see the leaderboard, check out how every country ranks at the 2018 Democracy Index.

Most of the countries in the list, notably those with the low ranking in red, openly pride themselves as being democratic and celebrate periodic elections where the populous get a chance to choose their leaders. But evidently, some democratic processes are prone to manipulation allowing existing leaders to maintain their positions of power regardless of where the populous tries to shift it.

Pseudo-democracies are not the only ones with problems. There are issues with the top 15% in the list. Take a look at the US for example, number 25 in the list and the historical epitome of modern democracy (no cynicism intended). “Gerrymandering” is one example of a US problem where the political party in power can draw lines between voting districts that are favorable to itself.

Democracies are complicated to implement, the nuances are plenty. And through their analysis and criticism, we have the chance to improve on them. To design processes that better guarantee their purity and withstand corruption.

Proof-of-Stake systems behave in a very similar way. Voting, or the degree of influence, is based on ownership of stake instead of citizenship, but otherwise, the process is prone to similar nuances and must be designed to withstand manipulation. We must also continuously criticize PoS implementations so we have the chance to improve them.

And surely — there is plenty of criticism of PoS in the crypto world. The spectrum ranges from belief that the problems of PoS are solvable, debating the pros and cons of various implementations, to outright skepticism whether PoS can work at all.

Take for example the views of Joseph Lubin, co-founder of Ethereum and founder of ConsenSys, from the recent Deconomy: “How about EOS? As has been debated endlessly, a platform controlled by 21 crypto bros is just not all that decentralized. They can collude and censor if they wish. Governments and other well resourced actor can bribe them or force them to act against their will and against the well being and the security of the people using the platform”.

Let’s try to analyze Lubin’s argument why EOS, the dominant PoS implementation to date, is flawed. The 21 elected nodes of EOS “can collude and censor if they wish.” But what would happen if these nodes indeed collude against the interests of the entire network? If the effects aren’t minor, like a decline in token price, stakeholders will spring to action and just replace the colluding nodes. Elections on EOS rely on stake of the entirety of the network, and the majority of stake is assumed to be honest. So where’s the risk?

The risk is only if the colluding nodes could prevent their own replacement. The core of the matter, in my opinion, is that they are the ones running the elections. They are the ones counting the votes.

This isn’t all that different from Cersei counting the Westeros votes by herself.

The majority of PoS implementations are closed systems. The voting process is part of the protocol and the protocol is executed by nodes running the network, that are chosen according to the protocol. There is an essence of circular trust here.

What about Proof-of-Work algorithms? Is PoW prone to the same circular trust weakness?

Not really. Albeit its shortcomings in terms of efficiency and cost, PoW has several wonderful properties making it an excellent choice for decentralized trust. The primary of which is strong objectivity.

Objectivity (I’m using Vitalik’s definition here) means that a new node coming onto the network with no knowledge except (i) the protocol definition and (ii) the set of all blocks and other “important” messages that have been published can independently come to the exact same conclusion as the rest of the network on the current state.

What does this mean? Let’s say I’m an observer of the network and I want to be convinced that the state presented by the nodes in the network is indeed the “correct” one. Am I able to verify everything all by myself?

I can easily verify the amount of work in PoW by myself (that’s the point, hashes are easy to verify but hard to produce). And since PoW algorithms work according to the longest chain rule, I can objectively know which competing portrayals of the state (competing forks) is the right one.

You can say, in a sense, that the work itself is external to the system, and since the system is not closed anymore and does not vouch for itself using itself only, it becomes very trustworthy.

The objectivity property is unique to PoW (and similar methods like VDFs) but missing from most PoS implementations, leading to the circular trust weakness of a closed system.

Why is the lack of objectivity painful in PoS networks? The core offering of these networks is trust. As clients of the network, we should be able to verify the correctness of the relevant state and transactions. Verifying the correctness of data requires knowledge of the elected validators, since they are the ones allowed to sign blocks. In order to verify the elected validators, one can attempt to verify the election calculations. However, the calculations and the votes reside on the chain itself, signed by the same validators that we’re trying to verify in the first place. This cyclic dependency prevents the client from objectively verifying the correctness of their data. There are workarounds like trusting one of the validators, but these solutions are suboptimal. When our core offering is trust, we should hold ourselves to a higher standard.

If we could add objectivity to PoS, this will provide us with the missing external oversight — and give us a PoS implementation that is much more trustworthy. This will also give a pretty good answer to Lubin’s fears that the elected nodes in the system can collude and censor (particularly regarding the voting process that elects them).

So, is it possible to use PoW for this purpose without affecting the efficiency of PoS? There is a straightforward way to do this and it’s actually pretty simple. All you have to do is store the votes externally — preferably on a different decentralized network that is based on PoW.

Going back to our Westeros example, this would mean that the voting booths where the ballots are stored, will no longer be under Lannister control. The voting booths will be controlled by somebody else (external to the Game of Thrones universe) that will guarantee the sanctity of the elections. Once the elections have been made, whichever king is elected, is free to rule inside Westeros without external involvement.

The last part is important. If we are to maintain the efficiency of PoS, the rest of the network operation — mainly executing smart contracts on the PoS network, storing the state under consensus, doing everything a blockchain does — must not rely on PoW anymore. The only thing PoW will provide is an external guarantee of objectivity that will let any observer confirm that the PoS network is not colluding and has indeed been purely elected.

This is how this approach is different from layer 2 solutions. Second layers delegate all security and trust to the base layer. The base layer can overturn smart contract results, for example, or override state modifications made by the second layer. Our approach will still make the PoS system retain its own security and trust and thus hold value of its own.

So how would that work in practice?

The natural choice for a PoW network to store election votes is Ethereum. It is popular and obviously secure enough (in terms of hash power) as a standard of trust to be sufficiently disconnected incentives-wise from our own PoS network; and its smart contracts offer the flexibility for a proper integration.

If storing election votes on Ethereum is a simple solution, why don’t we see more PoS blockchains taking this approach?

One reason may be ego. Many PoS systems position themselves as potential “Ethereum-killers” — the scalable place to run apps until Ethereum reaches its own scalability milestones. Elections are also a crucial part of your solution, and using somebody else for a crucial part may “leak” some of your own perceived value to this somebody. We don’t share these views at Orbs. We see enormous value in existing ecosystems that have already been built. Not everything has to be replaced. We attempt to use existing infrastructures where they show advantage in order to make our own solution better.

Another reason this approach is difficult for many PoS blockchains is the utility of the token used for staking. Most PoS systems rely on the token for settlement related to the main purpose of these platforms — running apps. In other words, app developers use the token to pay nodes for running their apps.

Performing staking on Ethereum will also mean the utility of payment for app execution will have to be done on Ethereum as well. Since most PoS systems rely on a per-transaction gas model and aim for very high transaction throughputs, this would make Ethereum fees (in Ether) extremely high and inefficient — and thus miss the whole point of the efficiency of PoS.

This is another place where the Orbs architecture comes to our advantage. We’ve made a product decision long ago (see the original Position Paper) to have apps pay monthly subscription fees to Orbs nodes for executing their apps, instead of a per-transaction gas model. This product decision brings multiple benefits crucial for a pragmatic app execution platform such as predictable fees and the ability for apps to subsidize their users’ fees to encourage adoption (the same way Facebook subsidizes your Messenger costs and doesn’t charge you for their infrastructure fees per sending each chat message). This is part of our strategy to bring the AWS product experience to app developers in blockchain.

Apps on Orbs run on virtual chains that have dedicated and isolated resources. Subscriptions for resource dedication in virtual chains are paid monthly (or even longer if you want to guarantee future data availability). Making the payment once a month on Ethereum means Ether fees are negligible. There will be no impact on the efficiency of PoS.

The Orbs network is a PoS-based blockchain. It relies on the ORBS token which is used for paying infrastructure fees for running apps and also for staking and electing validators. The voting process is performed on Ethereum and thus ORBS is an ERC20 token.

Orbs is not a layer 2 for Ethereum though. Orbs does not delegate security and trust to Ethereum and holds its own value in its permissionless validator pool based on the PoS ecosystem of the ORBS token and its incentives model. Ethereum provides an external objective guarantee that any observer can verify that elected nodes on Orbs are indeed the ones the stakeholders voted for. For this important governance function, Ethereum is a crucial component in the Orbs design.

Apps running on Orbs are not executed on Ethereum, allowing them to fully enjoy the efficiency and decentralization in PoS, extremely low operation fees, extremely high scale and many other Orbs-specific benefits such as governance isolation, smart contracts in any language and more.

Learn more about Orbs here.

btw — I’m going to be in NY for blockchain week (May 10–16 2019), if you want to say hello, tweet me at @koltal

Originally published at https://www.orbs.com on May 2, 2019.

What ‘Game of Thrones’ Teaches Us About Proof-Of-Stake — Don’t Trust Cersei!! was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Trying to unlock mainstream adoption for public blockchain is one of the hardest challenges in the industry today. Real businesses are yet to see the value in public blockchain technology and adoption crawls. I believe this is largely caused by the blockchain dichotomy: The polarization of infrastructure solutions in the industry today. If this indeed is the cause, we can design architectures around it. Will this be enough to make mainstream adoption possible?

There’s a feeling in the industry that blockchain is slow to deliver on its promise. The impact of this technology on the world is still small. This may be the result of unrealistic expectations due to the abundance of hype, but there’s no argument that the market is slow to mature.

We are past the point of demonstrating the conceptual innovation in blockchain. It is undeniable that this technology is capable of solving problems that we’ve previously had no solution for. But why are mainstream businesses barely using it to solve real world problems? Why is there so little adoption?

I talk to many tech companies. Almost all of them have looked into the technology. Many have even assigned a product manager to analyze the field. But when I ask this product manager what immediate value they see in public blockchain, they struggle to give a straightforward answer. Unsurprisingly, most of them don’t have concrete plans to incorporate the technology in their roadmaps. Most of them even struggle to provide one solid use-case where it can be used.

The blockchain dichotomy

I believe adoption is slow because our industry is severely polarized. Solutions are moving between two opposite extremes — and mainstream adoption is falling right in the gap.

On the one hand, we have public blockchains like Ethereum, Tezos and Polkadot. Beautiful solutions, but their approach to ‘publicness’ focuses on absolute decentralization of businesses. Their public offering resonates mostly with pure dapps, a new type of business model that is just emerging. They aim for a new Internet, where middlemen like Uber Ltd are replaced with new decentralized Ubers, incorporating peer-to-peer token economies instead of the traditional for-profit model of the business world. The problem these infrastructures are solving today is not in high demand from existing mainstream businesses and their optimizations make them too expensive and impractical for popular use.

On the other hand, we have private and permissioned blockchains like Hyperledger. They are pragmatic and easy to use, but provide questionable benefit over traditional databases. They don’t focus on the value of permissionlessness and therefore cannot give strong external guarantees to their users. I believe these solutions miss out on what is truly disruptive about blockchain and where the big value awaits.

Is it possible to bridge this dichotomy? Or is this polarization inherent to the nature of the technology itself?

What are we trying to solve, anyways?

Before we can start thinking about architectures for bridging dichotomies, we need concrete definitions for what we’re trying to solve. The value-add of the technology isn’t clear to mainstream businesses. So, what is the purpose of the public blockchain?

The first thing people say as a response to this question is usually decentralization — we’re trying to decentralize aspects of business. When trying to pitch decentralization to a business, the first question asked is will decentralization make me more profitable? The industry is struggling to provide a convincing answer to this question.

I prefer a different answer. I see pragmatic blockchain technology as the infrastructure to build applications that provide three interesting guarantees to users: auditability, forkability and governance. I won’t go into detail about each guarantee, it is covered in a previous post. These guarantees can help make businesses more profitable, see analogies from the open source movement.

Now, that we have a concrete answer, we can explore how these guarantees are actually given.

Block producers and validators

Block producers, validators, miners — are all similar terms in blockchain architecture. They refer to the entities in the network that are charged with selecting transactions, packing them inside blocks and signing these blocks as part of the consensus process. Every block that passes consensus is added to the chain, thus creating the block chain.

The first interesting distinction we’re making in Orbs is separating between block producers and validators. Block producers are the ones proposing blocks, validators are the ones signing and verifying them.

The consensus process in the network adds blocks to the chain one after the other. When work starts on a new block, one of the block producers chooses transactions that will go into this block and packs them inside. This includes executing the transactions, recording the changes in state and so forth.

Now, that a new block is proposed, it must undergo consensus. This block is sent to validators which verify that the block follows the protocol. They verify that indeed the transactions are valid, that execution is correct, the state changes add up and so forth. If valid, they sign the block. When enough signatures are collected — beyond the consensus threshold — the block is accepted and added to the chain.

Many blockchain architectures today use the same entities for both tasks. Block producers usually act as validators for each other. There is normally only one group.

Making the separation between the two possible in the Orbs architecture provides some interesting benefits and in my eyes plays a major part in the solution.

Proof-of-stake and a public pool of validators

At the heart of the Orbs ecosystem is a permissionless pool of validators that is elected by ORBS token holders. I will not go into the specifics of the Orbs proof-of-stake architecture and how guardians and delegators work together to accomplish this task. See relevant posts on the subject.

I will only emphasize that the purpose of the Orbs incentives model is to actively maintain a quality pool of trustworthy validators that act in the best interest of the network and uphold the protocol. These validators are public in essence, chosen in a decentralized and permissionless way, as common in other proof-of-stake models prevalent in the industry.

Virtual chains and governance autonomy of apps

Another important element of the architecture is virtual chains. The Orbs network runs multiple isolated virtual chains in parallel on the same physical infrastructure of nodes and validators. Every app would normally run on its own virtual chain under the illusion of having its own dedicated blockchain.

There are many benefits to this approach, from infinite horizontal scalability (virtual chains are inherently sharded) to the ability to provide apps with dedicated and reserved resources that guarantee performance.

The most important benefit though is not related to performance, it has to do with isolation. Different virtual chains are isolated, particularly in regard to governance. Every virtual chain has its own chain of blocks advancing independently and its own instance of the consensus algorithm executing in parallel.

This means that if an app has a catastrophic bug, like in the case of The DAO, an extreme governance decision like changing history would not impact the other virtual chains. Their blocks would not be affected.

Every app is required to declare and implement its governance model as a set of smart contracts running in its virtual chain. This enables each virtual chain to make its own independent governance decisions, like choosing its consensus algorithm. What else should we let every app control?

Can apps choose block producers and validators?

If an app is free to make governance decisions in its virtual chain, the immediate question becomes: Can an app choose its own block producers? Moreover, can an app choose its own validators?

It turns out this question is one of the most profound ones any blockchain infrastructure has to answer. Let’s explore the matrix of possibilities:

1. Apps can’t choose their own block producers, apps can’t choose their own validators

If we’re not letting the app choose the identities of either group, this means both groups must be designated by the network. In the Orbs case, it means both groups come from the permissionless validator pool elected by ORBS token holders according to the Orbs proof-of-stake model.

This approach takes us to the extreme “public” side of the blockchain dichotomy. It is similar in concept to how blockchains like Ethereum and Tezos work today. Apps running on these blockchains must naturally accept the public miners of these blockchains — assembled using incentives systems unrelated to the app.

2. Apps can choose their own block producers, apps can choose their own validators

If we’re letting the app choose the identities of both groups, the app does not rely on the public validator pool at all. This means effectively that the app’s block producers and validators are subject to the governance model of the app itself.

If the app governance is permissioned (eg. some entity under the app calls the shots), these groups will be permissioned. If the app governance is permissionless (eg. proof-of-stake using the app’s secondary token), these groups will be permissionless but subject to the app’s own incentive model — not the network’s. The repercussions from this are vast and probably deserve their own dedicated blog post.

This approach takes us to the extreme “private” side of the blockchain dichotomy. It is similar in concept to how blockchains like Hyperledger work. Apps running on these blockchains control their own private fate.

These are the two extremes we’re well familiar with. Is there a third option?

3. Apps can choose their own block producers, but cannot choose their own validators

Now things are beginning to get interesting under the Orbs architecture. Block producers can be chosen by the app — subject to whatever governance model the app has (permissioned or permissionless), but the validators are designated by the network — coming from the Orbs public and permissionless validator pool elected by ORBS token holders.

It seems that this approach does not fall under any of the extremes of the dichotomy. It falls somewhere in the middle.

And this is exciting.

Back to our three guarantees

We’ve defined earlier pragmatic blockchain technology as the infrastructure to build applications that provide three interesting guarantees to users: auditability, forkability and governance.

Let’s explore forkability for a minute because it’s arguably the most interesting of the three. Forkability is the ability of every app user to fork the app at will, with all of its code and data. The ability to fork creates a healthy balance of power. If control of the app is abused and a community of users or partners feel wronged by whichever app governance model was chosen, this community can easily run its own duplicate instance of the app. They are not held hostage. If this does not happen and the app remains the popular fork, this means no other fork is doing a better job. This sums up forkability.

So, what do we need in order to guarantee app users the ability to fork?

This is actually pretty simple. All they need is access to all the blocks in the app’s virtual chain. Since smart contracts are stored on state, and state changes are stored on blocks, both code and data will be available this way.

The act of forking a virtual chain is trivial on Orbs. The platform allows you to create a new forked virtual chain instance at the click of a button, containing all blocks from the original virtual chain.

But how can we guarantee access to the app’s blocks? How can we guarantee that the blocks we are shown are indeed the real blocks and not some alternate history?

We can do that if an external pool of validators has verified access to the original blocks; A pool of validators that is not under the direct control of the app; A public pool of validators. Just like the one elected by the ORBS token holders under the Orbs Universe!

Comparing the matrix of choices

Both extremes of the dichotomy are possible under the Orbs architecture but both have significant disadvantages for the mainstream.

Forcing the public pool of network validators for the app’s block producers and validators is the “public” extreme. It is possible to give the three guarantees this way, but the hosted app becomes absolutely decentralized. This would be expensive and impractical for many mainstream businesses. Nevertheless, this approach is supported and works well for pure dapps.

Giving the app full control of its block producers and validators is the “private” extreme. It is very practical for mainstream businesses, but it turns out that it is not possible to give the three guarantees this way. Therefore, this approach misses out on what we’ve defined as the value-add of blockchain. The app might as well run on a plain old database instead.

But what about the third option? Control over block producers, but no control over validators.

Forcing the public pool of network validators for the app’s validators turns out to be enough to provide us with all three guarantees. This means the value-add of blockchain is there. Yet, giving the app control of its block producers makes a big difference — it makes the solution suddenly much more practical for mainstream businesses. Why is that?

Control of block producers is important for mainstream adoption

Giving a mainstream app control of its block producers alleviates many of the fears of decentralizing too aggressively. It makes the process of migrating to blockchain feasible for existing businesses.

First, it takes care of concerns about security. This may seem counter intuitive, but for mainstream apps, switching to the fully decentralized security model of blockchain actually adds risk. Uber does not have substantial security concerns, it’s perfectly confident in own its ability to secure its own app in a centralized way. Uber will not switch to blockchain for the security. If anything, Uber will avoid switching to blockchain for the fear of giving an unknown group of anonymous nodes full control of its own security.

Controlling its block producers will allow Uber to act as its own block producer. If they don’t trust anyone else, they can even be the only block producer, keeping their fate in their own hands. External validators only verify blocks, they don’t propose them. Even if all validators collude against Uber, they won’t be able to change data or steal anything. The maximum damage they can do is impact the liveness of the app. And that’s not necessarily a bad thing, because if Uber itself is compromised by bad actors, these validators will prevent bad actors from doing damage to the users.

Second, this reduces costs, dramatically. One of the biggest downsides of blockchain for mainstream businesses is that running on blockchain is thousands of times more expensive than the alternative. The value-add of blockchain has to be immense for this to make sense. And this unfortunately isn’t the case for most apps.

Running a validator is significantly cheaper than running a block producer. Validators can be stateless. For Uber, running its own block producers is not very different cost-wise from running its own servers as it does today. The extra costs of blockchain are reflected in the overhead payment for the validators of the public pool.

Third, the focus on adding guarantees for users, and not on absolute decentralization. The idea is not to tear down Uber and replace it with a new fully decentralized Uber. This is not practical, particularly not for Uber Ltd. We’re not trying to build a new Internet. We’re trying to improve existing apps and make them more attractive to users and partners by helping them offer stronger guarantees. Defining the value-add of public blockchain as the ability to give these guarantees, and not as absolute decentralization, suddenly makes the value-add of blockchain applicable for the mainstream.

Gradual and responsible decentralization for apps

The Orbs architecture provides apps with several degrees of control that make migration to blockchain a potentially gradual process. This stems from our realization that most existing businesses cannot decentralize overnight.

How is this made possible for an app?

First, by giving it independent governance. The fact that every virtual chain is free to make its own governance decisions, means that decisions of one app do not affect another. Every app can decentralize in its own pace.

Second, by controlling its block producers. An existing app can start by being its own only block producer. The platform is still able to provide the three guarantees in this case. As the app is ready to trust additional partners, for example when expanding its ecosystem, it can add additional block producers from trusted partners. The final step will be making its block producer pool permissionless. The app can do this under its own incentive model or use the public permissionless validator pool of Orbs for the task. This would make the final step into the “public” extreme of the dichotomy — but only if and when the app is ready.

If desired, it is also possible for the app to start from the “private” extreme of the dichotomy and even control its own validators. As we’ve seen before, the benefit of blockchain in this case is small, because the three guarantees will not be given. The value-add of blockchain will not manifest. Nevertheless, apps that only desire to be public-ready can start experimenting with the technology this way.

Third, by evolving its own governance model. The governance model of an app is implemented as smart contracts running on its virtual chain. This governance model can start centralized with one entity making all decisions. This gives existing apps control but doesn’t impact the platform’s ability to offer the three guarantees. As the app’s desire to decentralize grows, this governance model can be upgraded to a more decentralized one. If the app has its own token economy, for example, it can use stake based votes on its own secondary token to make internal governance decisions in a purely decentralized way.

Conclusion

The blockchain dichotomy is holding blockchain adoption back. Solutions today are either overly decentralized on the “public” extreme or overly permissioned on the “private” extreme. We can either tear down existing applications and build a new Internet or stay behind with the old Internet and miss out on everything blockchain can offer.

Separating between block producers and validators may provide the missing flexibility. Allowing block producers to remain “private” while forcing validators to become “public” allows mainstream applications to retain a level of control and keep infrastructure costs sane.

This approach is still able to offer the public essence of blockchain — of open ecosystems and trustless decentralized collaboration that can make businesses more competitive. Allowing existing apps to give strong guarantees to their users and partners — auditability, forkability, and governance — is what public blockchain should really be about.

I believe that the dichotomy we’re seeing today will gradually disappear. Both extremes will have to take steps to become closer. Solutions on the “public” extreme like Ethereum and Tezos will become more appealing to the mainstream by adopting architectures like separating block producers and validators. Solutions on the “private” extreme will add Byzantine fault tolerance and other ideas from public blockchains to provide stronger guarantees to their users.

Get involved with Orbs

• Visit the website to learn more about the Orbs public blockchain
• Orbs is open source! Review the code on Github and contribute
• Start developing apps on Orbs, review the documentation

Originally published at https://www.orbs.com on April 15, 2019.

The Blockchain Dichotomy and an Architecture to Overcome It was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Trying to unlock mainstream adoption for public blockchain is one of the hardest challenges in the industry today. Real businesses are yet to see the value in public blockchain technology and adoption crawls. I believe this is largely caused by the blockchain dichotomy: The polarization of infrastructure solutions in the industry today. If this indeed is the cause, we can design architectures around it. Will this be enough to make mainstream adoption possible?

There’s a feeling in the industry that blockchain is slow to deliver on its promise. The impact of this technology on the world is still small. This may be the result of unrealistic expectations due to the abundance of hype, but there’s no argument that the market is slow to mature.

We are past the point of demonstrating the conceptual innovation in blockchain. It is undeniable that this technology is capable of solving problems that we’ve previously had no solution for. But why are mainstream businesses barely using it to solve real world problems? Why is there so little adoption?

I talk to many tech companies. Almost all of them have looked into the technology. Many have even assigned a product manager to analyze the field. But when I ask this product manager what immediate value they see in public blockchain, they struggle to give a straightforward answer. Unsurprisingly, most of them don’t have concrete plans to incorporate the technology in their roadmaps. Most of them even struggle to provide one solid use-case where it can be used.

The blockchain dichotomy

I believe adoption is slow because our industry is severely polarized. Solutions are moving between two opposite extremes — and mainstream adoption is falling right in the gap.

On the one hand, we have public blockchains like Ethereum, Tezos and Polkadot. Beautiful solutions, but their approach to ‘publicness’ focuses on absolute decentralization of businesses. Their public offering resonates mostly with pure dapps, a new type of business model that is just emerging. They aim for a new Internet, where middlemen like Uber Ltd are replaced with new decentralized Ubers, incorporating peer-to-peer token economies instead of the traditional for-profit model of the business world. The problem these infrastructures are solving today is not in high demand from existing mainstream businesses and their optimizations make them too expensive and impractical for popular use.

On the other hand, we have private and permissioned blockchains like Hyperledger. They are pragmatic and easy to use, but provide questionable benefit over traditional databases. They don’t focus on the value of permissionlessness and therefore cannot give strong external guarantees to their users. I believe these solutions miss out on what is truly disruptive about blockchain and where the big value awaits.

Is it possible to bridge this dichotomy? Or is this polarization inherent to the nature of the technology itself?

What are we trying to solve, anyways?

Before we can start thinking about architectures for bridging dichotomies, we need concrete definitions for what we’re trying to solve. The value-add of the technology isn’t clear to mainstream businesses. So, what is the purpose of the public blockchain?

The first thing people say as a response to this question is usually decentralization — we’re trying to decentralize aspects of business. When trying to pitch decentralization to a business, the first question asked is will decentralization make me more profitable? The industry is struggling to provide a convincing answer to this question.

I prefer a different answer. I see pragmatic blockchain technology as the infrastructure to build applications that provide three interesting guarantees to users: auditability, forkability and governance. I won’t go into detail about each guarantee, it is covered in a previous post. These guarantees can help make businesses more profitable, see analogies from the open source movement.

Now, that we have a concrete answer, we can explore how these guarantees are actually given.

Block producers and validators

Block producers, validators, miners — are all similar terms in blockchain architecture. They refer to the entities in the network that are charged with selecting transactions, packing them inside blocks and signing these blocks as part of the consensus process. Every block that passes consensus is added to the chain, thus creating the block chain.

The first interesting distinction we’re making in Orbs is separating between block producers and validators. Block producers are the ones proposing blocks, validators are the ones signing and verifying them.

The consensus process in the network adds blocks to the chain one after the other. When work starts on a new block, one of the block producers chooses transactions that will go into this block and packs them inside. This includes executing the transactions, recording the changes in state and so forth.

Now, that a new block is proposed, it must undergo consensus. This block is sent to validators which verify that the block follows the protocol. They verify that indeed the transactions are valid, that execution is correct, the state changes add up and so forth. If valid, they sign the block. When enough signatures are collected — beyond the consensus threshold — the block is accepted and added to the chain.

Many blockchain architectures today use the same entities for both tasks. Block producers usually act as validators for each other. There is normally only one group.

Making the separation between the two possible in the Orbs architecture provides some interesting benefits and in my eyes plays a major part in the solution.

Proof-of-stake and a public pool of validators

At the heart of the Orbs ecosystem is a permissionless pool of validators that is elected by ORBS token holders. I will not go into the specifics of the Orbs proof-of-stake architecture and how guardians and delegators work together to accomplish this task. See relevant posts on the subject.

I will only emphasize that the purpose of the Orbs incentives model is to actively maintain a quality pool of trustworthy validators that act in the best interest of the network and uphold the protocol. These validators are public in essence, chosen in a decentralized and permissionless way, as common in other proof-of-stake models prevalent in the industry.

Virtual chains and governance autonomy of apps

Another important element of the architecture is virtual chains. The Orbs network runs multiple isolated virtual chains in parallel on the same physical infrastructure of nodes and validators. Every app would normally run on its own virtual chain under the illusion of having its own dedicated blockchain.

There are many benefits to this approach, from infinite horizontal scalability (virtual chains are inherently sharded) to the ability to provide apps with dedicated and reserved resources that guarantee performance.

The most important benefit though is not related to performance, it has to do with isolation. Different virtual chains are isolated, particularly in regard to governance. Every virtual chain has its own chain of blocks advancing independently and its own instance of the consensus algorithm executing in parallel.

This means that if an app has a catastrophic bug, like in the case of The DAO, an extreme governance decision like changing history would not impact the other virtual chains. Their blocks would not be affected.

Every app is required to declare and implement its governance model as a set of smart contracts running in its virtual chain. This enables each virtual chain to make its own independent governance decisions, like choosing its consensus algorithm. What else should we let every app control?

Can apps choose block producers and validators?

If an app is free to make governance decisions in its virtual chain, the immediate question becomes: Can an app choose its own block producers? Moreover, can an app choose its own validators?

It turns out this question is one of the most profound ones any blockchain infrastructure has to answer. Let’s explore the matrix of possibilities:

1. Apps can’t choose their own block producers, apps can’t choose their own validators

If we’re not letting the app choose the identities of either group, this means both groups must be designated by the network. In the Orbs case, it means both groups come from the permissionless validator pool elected by ORBS token holders according to the Orbs proof-of-stake model.

This approach takes us to the extreme “public” side of the blockchain dichotomy. It is similar in concept to how blockchains like Ethereum and Tezos work today. Apps running on these blockchains must naturally accept the public miners of these blockchains — assembled using incentives systems unrelated to the app.

2. Apps can choose their own block producers, apps can choose their own validators

If we’re letting the app choose the identities of both groups, the app does not rely on the public validator pool at all. This means effectively that the app’s block producers and validators are subject to the governance model of the app itself.

If the app governance is permissioned (eg. some entity under the app calls the shots), these groups will be permissioned. If the app governance is permissionless (eg. proof-of-stake using the app’s secondary token), these groups will be permissionless but subject to the app’s own incentive model — not the network’s. The repercussions from this are vast and probably deserve their own dedicated blog post.

This approach takes us to the extreme “private” side of the blockchain dichotomy. It is similar in concept to how blockchains like Hyperledger work. Apps running on these blockchains control their own private fate.

These are the two extremes we’re well familiar with. Is there a third option?

3. Apps can choose their own block producers, but cannot choose their own validators

Now things are beginning to get interesting under the Orbs architecture. Block producers can be chosen by the app — subject to whatever governance model the app has (permissioned or permissionless), but the validators are designated by the network — coming from the Orbs public and permissionless validator pool elected by ORBS token holders.

It seems that this approach does not fall under any of the extremes of the dichotomy. It falls somewhere in the middle.

And this is exciting.

Back to our three guarantees

We’ve defined earlier pragmatic blockchain technology as the infrastructure to build applications that provide three interesting guarantees to users: auditability, forkability and governance.

Let’s explore forkability for a minute because it’s arguably the most interesting of the three. Forkability is the ability of every app user to fork the app at will, with all of its code and data. The ability to fork creates a healthy balance of power. If control of the app is abused and a community of users or partners feel wronged by whichever app governance model was chosen, this community can easily run its own duplicate instance of the app. They are not held hostage. If this does not happen and the app remains the popular fork, this means no other fork is doing a better job. This sums up forkability.

So, what do we need in order to guarantee app users the ability to fork?

This is actually pretty simple. All they need is access to all the blocks in the app’s virtual chain. Since smart contracts are stored on state, and state changes are stored on blocks, both code and data will be available this way.

The act of forking a virtual chain is trivial on Orbs. The platform allows you to create a new forked virtual chain instance at the click of a button, containing all blocks from the original virtual chain.

But how can we guarantee access to the app’s blocks? How can we guarantee that the blocks we are shown are indeed the real blocks and not some alternate history?

We can do that if an external pool of validators has verified access to the original blocks; A pool of validators that is not under the direct control of the app; A public pool of validators. Just like the one elected by the ORBS token holders under the Orbs Universe!

Comparing the matrix of choices

Both extremes of the dichotomy are possible under the Orbs architecture but both have significant disadvantages for the mainstream.

Forcing the public pool of network validators for the app’s block producers and validators is the “public” extreme. It is possible to give the three guarantees this way, but the hosted app becomes absolutely decentralized. This would be expensive and impractical for many mainstream businesses. Nevertheless, this approach is supported and works well for pure dapps.

Giving the app full control of its block producers and validators is the “private” extreme. It is very practical for mainstream businesses, but it turns out that it is not possible to give the three guarantees this way. Therefore, this approach misses out on what we’ve defined as the value-add of blockchain. The app might as well run on a plain old database instead.

But what about the third option? Control over block producers, but no control over validators.

Forcing the public pool of network validators for the app’s validators turns out to be enough to provide us with all three guarantees. This means the value-add of blockchain is there. Yet, giving the app control of its block producers makes a big difference — it makes the solution suddenly much more practical for mainstream businesses. Why is that?

Control of block producers is important for mainstream adoption

Giving a mainstream app control of its block producers alleviates many of the fears of decentralizing too aggressively. It makes the process of migrating to blockchain feasible for existing businesses.

First, it takes care of concerns about security. This may seem counter intuitive, but for mainstream apps, switching to the fully decentralized security model of blockchain actually adds risk. Uber does not have substantial security concerns, it’s perfectly confident in own its ability to secure its own app in a centralized way. Uber will not switch to blockchain for the security. If anything, Uber will avoid switching to blockchain for the fear of giving an unknown group of anonymous nodes full control of its own security.

Controlling its block producers will allow Uber to act as its own block producer. If they don’t trust anyone else, they can even be the only block producer, keeping their fate in their own hands. External validators only verify blocks, they don’t propose them. Even if all validators collude against Uber, they won’t be able to change data or steal anything. The maximum damage they can do is impact the liveness of the app. And that’s not necessarily a bad thing, because if Uber itself is compromised by bad actors, these validators will prevent bad actors from doing damage to the users.

Second, this reduces costs, dramatically. One of the biggest downsides of blockchain for mainstream businesses is that running on blockchain is thousands of times more expensive than the alternative. The value-add of blockchain has to be immense for this to make sense. And this unfortunately isn’t the case for most apps.

Running a validator is significantly cheaper than running a block producer. Validators can be stateless. For Uber, running its own block producers is not very different cost-wise from running its own servers as it does today. The extra costs of blockchain are reflected in the overhead payment for the validators of the public pool.

Third, the focus on adding guarantees for users, and not on absolute decentralization. The idea is not to tear down Uber and replace it with a new fully decentralized Uber. This is not practical, particularly not for Uber Ltd. We’re not trying to build a new Internet. We’re trying to improve existing apps and make them more attractive to users and partners by helping them offer stronger guarantees. Defining the value-add of public blockchain as the ability to give these guarantees, and not as absolute decentralization, suddenly makes the value-add of blockchain applicable for the mainstream.

Gradual and responsible decentralization for apps

The Orbs architecture provides apps with several degrees of control that make migration to blockchain a potentially gradual process. This stems from our realization that most existing businesses cannot decentralize overnight.

How is this made possible for an app?

First, by giving it independent governance. The fact that every virtual chain is free to make its own governance decisions, means that decisions of one app do not affect another. Every app can decentralize in its own pace.

Second, by controlling its block producers. An existing app can start by being its own only block producer. The platform is still able to provide the three guarantees in this case. As the app is ready to trust additional partners, for example when expanding its ecosystem, it can add additional block producers from trusted partners. The final step will be making its block producer pool permissionless. The app can do this under its own incentive model or use the public permissionless validator pool of Orbs for the task. This would make the final step into the “public” extreme of the dichotomy — but only if and when the app is ready.

If desired, it is also possible for the app to start from the “private” extreme of the dichotomy and even control its own validators. As we’ve seen before, the benefit of blockchain in this case is small, because the three guarantees will not be given. The value-add of blockchain will not manifest. Nevertheless, apps that only desire to be public-ready can start experimenting with the technology this way.

Third, by evolving its own governance model. The governance model of an app is implemented as smart contracts running on its virtual chain. This governance model can start centralized with one entity making all decisions. This gives existing apps control but doesn’t impact the platform’s ability to offer the three guarantees. As the app’s desire to decentralize grows, this governance model can be upgraded to a more decentralized one. If the app has its own token economy, for example, it can use stake based votes on its own secondary token to make internal governance decisions in a purely decentralized way.

Conclusion

The blockchain dichotomy is holding blockchain adoption back. Solutions today are either overly decentralized on the “public” extreme or overly permissioned on the “private” extreme. We can either tear down existing applications and build a new Internet or stay behind with the old Internet and miss out on everything blockchain can offer.

Separating between block producers and validators may provide the missing flexibility. Allowing block producers to remain “private” while forcing validators to become “public” allows mainstream applications to retain a level of control and keep infrastructure costs sane.

This approach is still able to offer the public essence of blockchain — of open ecosystems and trustless decentralized collaboration that can make businesses more competitive. Allowing existing apps to give strong guarantees to their users and partners — auditability, forkability, and governance — is what public blockchain should really be about.

I believe that the dichotomy we’re seeing today will gradually disappear. Both extremes will have to take steps to become closer. Solutions on the “public” extreme like Ethereum and Tezos will become more appealing to the mainstream by adopting architectures like separating block producers and validators. Solutions on the “private” extreme will add Byzantine fault tolerance and other ideas from public blockchains to provide stronger guarantees to their users.

Get involved with Orbs

• Visit the website to learn more about the Orbs public blockchain
• Orbs is open source! Review the code on Github and contribute
• Start developing apps on Orbs, review the documentation

The Blockchain Dichotomy and an Architecture to Overcome It was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s little argument that open source has transformed our world. As a developer, I cannot recall a single day in the last few years where I did not rely on open source software. I’m not the exception. The majority of software engineers today rely on open source daily in their professional lives.

For one, open source is dominating developer infrastructure. From operating systems (Linux in the cloud) to databases (MySQL, MongoDB, Redis) to programming languages themselves (JavaScript, Python, Java, C, PHP). It’s not just developers, it’s consumers as well. From what they run on their phones (Android) to how they access the web (Chrome, Firefox).

The motivation is clear. Open source is good for humanity. It is making technology more accessible and open — anyone can build anything.

Open source was not always mainstream

If you had asked a random developer 20 years ago whether this idea of open software would ever catch on, they would have laughed. Sharing intellectual property, your competitive advantage? absurd. Would it affect real business? barely, it’s a niche. The ones leading it? anarchists, trying to tear down establishments.

This is not very far from how many people view blockchain today. Decentralizing control when you can hold on to it? absurd. What is the business use-case? not mainstream, a niche. The ones leading it? anarchists, trying to tear down institutions.

With blockchain, it’s actually worse. The inflated cryptocurrency bubble and its recent recession, the abundance of opportunism and over-speculation, are all adding even more suspicion to the mix.

Open source and for-profit companies

In the beginning it seemed that open source and for-profit companies were mutually exclusive. Corporations like Microsoft were hailed as the enemies of open source. Companies saw code as their secret-sauce, which sharing would bring-about their downfall or destroy their competitive edge. Today, nothing is further from the truth.

The biggest contributors to open source today are for-profit enterprises like Microsoft, Google, IBM and Facebook. These companies are leading many of the most popular projects like React and TensorFlow. Personally, I was lucky to be part of such a company, Wix.com, and help take it from a walled-garden to number 11 in some obscure ranked list of global open source contributors in 2017.

Why are these companies choosing to open parts of their IP? Well, it’s certainly not because of ideology. Open source is making these companies more competitive.

A good example is Google with Android. Google was late to the coveted space of mobile already predominated by Apple with the transformative release of the iPhone. Microsoft was late as well (technically they were there first but with the wrong product), with more years of operating system domination than the other two combined. Penetrating this emerging market was no easy task.

Part of Google’s strategy was relying on a largely open source operating system, Android. Manufacturers like Samsung would have otherwise found it hard to join — basing critical parts of their business on an ecosystem they have zero control over would be unwise. This strategy paid off. The Android ecosystem grew as the open answer to Apple’s closed garden. Google did forgo the ability to sell licenses for this property, but gained something much more valuable: presence in the pockets of over a quarter of the population of Earth.

The same debate is taking place today about blockchain. Why would for-profit companies, market leaders especially, ever opt to decentralize any part of their business? Isn’t their position of power linked to centralized control?

I argue that they will do so for the same exact reason. Not because of ideology, but because it will make them more competitive. To maintain their positions of influence they will have to make ecosystems that are more open. Otherwise, their competitors will, and win.

Forks, control and the balance of power

We’ve seen why a company like Facebook would release IP like React — a project that transformed the way web frontend is built. What is less clear is why other companies would adopt Facebook’s native technology for their own critical-business paths.

I was fortunate to have had a front row seat to such a decision. When I was at Wix.com there was a debate on whether to base the Wix.com website editor on React. For a company that creates websites for a living, risking the editor is risking the lifeline of the company as a whole.

Imagine that one day Facebook decides to compete with Google for web domination and releases its own web browser as an alternative to Chrome. Significant parts of the web are based on React. What if, in this dystopian future, Facebook decides to make React incompatible with Chrome? This decision could jeopardize Wix.com’s business.

The governance of open source is successful mainly due to the concept of forks. Anyone can take the entire source code of any open source project and make a copy that they control, at the click of a button. If Facebook would ever make React incompatible with Google Chrome, Wix.com can fork React and create a version that is compatible. If the community favors this fork to the one Facebook is maintaining, they would adopt it. At some point, the more popular fork would actually become “the” React in the eyes of the public.

This delicate balance keeps Facebook in check. Facebook may maintain its position of influence as long as it doesn’t abuse it. Where does the line cross? where the consensus says it does.

This sounds awfully close to how blockchain governance works. This same guarantee of the ability to fork is one of the core guarantees this technology provides to its users. One thing to notice is that this guarantee is much stronger under blockchain. Beyond the source code of the system, you can fork all of its data as well.

A continuation of the open source movement

We’ve drawn several parallels between open source and blockchain. We’ve seen similar regard to both movements in their early days. We’ve seen similar motivations of openness. We’ve seen the same questions whether for-profit companies fit in. We’ve seen the same governance and balance of power.

I argue that it’s more than mere coincidence. I see Blockchain as a continuation of the open source movement, picking up where this left off.

There’s a clear limit to what can be shared with open source. Open source cannot open up live systems, it cannot open their data. You can share the source code for a server, but naturally you cannot share a running instance of this server.

Blockchain is making this next step technologically possible.

A concrete example

Let’s go back to Android. We’ve seen the value the ecosystem derives from having control of the operating system source code — this value allowed companies like Samsung to join in and made this ecosystem attractive.

But Android is not just source code. There are many living services required for the ecosystem to function. Android relies on push notifications, it relies on payments, it relies on apps being downloaded from Google Play. These services are all running instances, not just code. Billions of users query them daily. They hold data.

Who is running those services? Let’s focus on Google Play. With a name like that the answer is self evident. Google is running these services on private infrastructure that isn’t shared with anyone.

What is the cost of having Google in sole control of Google Play? For starters, a 30% fee every developer pays Google for the benefit of distributing their app digitally. But that’s just money. Every mobile developer has felt the uneasiness with the app approval process. Less fortunate ones have experienced app rejection and the 3 strike suspension policy. Absolute control of a distribution channel where said company’s own products are being sold and distributed can’t be good for competition. See what’s going on with Spotify in the Apple store.

What about competing app stores on Android? They’re possible, Amazon did a great job of building an alternative. Unfortunately these alternatives cannot resolve the fundamental problems and offer little differentiation.

Being able to run a service like Google Play together would provide a great value to the Android ecosystem. Such an idea is not technically possible with open source alone.

It is technically possible with blockchain though, I will be more than happy to show a proof of concept in one of my future posts. But let’s be honest, we won’t see this happening any time soon. A community run decentralized Google Play isn’t practical enough today primarily for business reasons.

Instead, I see a different opportunity. An opportunity for a for-profit giant like Microsoft, desperate to carve some niche in the mobile space. Building an app distribution channel that is not completely centralized. Giving a few more guarantees to the developers who are relying on it. Not because of ideology, but because it will make the offering more competitive — more competitive than Google Play and Amazon Appstore at least.

Blockchain will become mainstream

I believe that history will show that every system that has multiple parties relying on it will eventually have to provide its users with some hard guarantees. Not for ideology, but to remain competitive.

This doesn’t mean that every system will run on blockchain. Just like every piece of software doesn’t have to be open source. But there is some critical part of the world that has to be open. Just like some critical parts of software must be open source for companies to be successful.

Tal is a founder at Orbs.com — a public blockchain by developers for developers. Contribute to the Orbs open source project on Github.

The purpose of this short post is to give a high level introduction to the Orbs Universe and its proof-of-stake ecosystem. This post will not go into the specifics of the mechanics and will not go into exact numbers (this information is available here). Instead, we’ll focus on motivation and the main idea.

The ideas in this post are simplified to make the model easier to understand. The following posts on the topic go into the specifics in a more precise and accurate way.

Validators

Validators play an essential role in the Orbs network. They operate the Orbs nodes, run the consensus algorithm, sign blocks and approve transactions for the decentralized apps. Validators should also provide assurances that they’re good actors and indeed follow the protocol.

• What skills are needed for being a good validator?
  Operating a node in a high throughput network like Orbs requires technical proficiency. The node should have high availability, it has to be fast, it has to be kept secure and updated. Running a node is a full-time profession. We want validators who are committed to this task and will develop the expertise needed for performing it well.
• What’s the incentive for being a validator?
  Validators are compensated for their service to the network since they do the heavy lifting of running the protocol and provide assurances for honesty. Part of the payment comes from fees, paid by apps for running their virtual chains. Another part comes from rewards given from the token reserve whose purpose is attracting quality validators in the early bootstrap years of the network.
• How many validators are needed?
  The network requires between several dozens to several hundreds of validators. The issue here is how to know whether a validator is good. Validators can abuse their position and cause damage to the network.

One of the goals of the proof-of-stake model is making sure the best validators are selected. This voting process is based on stake because almost every other method is susceptible to manipulation.

Optimizing the voting process

If stake in the network is used for voting and electing validators, we can identify two main goals for optimizing this process:

1. Have as much stake as possible participate. Electing validators is an important task. Since proof-of-stake models assume that the majority of stake in the network is honest, the more stake we get to participate, the harder it will be to manipulate the results and compromise the network.
2. Encourage educated votes and proper due diligence. If we could get all stake to participate but every voter would just choose a result randomly, would this benefit the network? Of course not. Votes are only meaningful if the voter has taken the time to make an educated selection.

It appears that these two goals are somewhat conflicting. Making an educated selection requires effort. The more effort we expect, the less participants we’ll find willing to make it. Pushing to increase the number of participants will naturally reduce the overall quality of participation.

One of the interesting things the model tries to do is solve this conflict.

Guardians

If we want to increase the quality of votes, let’s try to characterize the ideal voter. We’ll call this voter a guardian because effort on their behalf — finding the best validators or rooting out problematic ones — is what’s essentially guarding the network and keeping it safe and secure.

• What skills are needed for being a good guardian?
  A good guardian can perform meaningful due diligence on a validator. This may require some technical proficiency like running an audit node to check who’s following the protocol or measure a node’s uptime. This may also require checking for reputation and trust by looking up company records for example. Due diligence has to be done continuously because voting is a frequent process. An elected validator that fails to perform must be taken out quickly. In addition, guardians are community leaders among stakeholders so ability to educate other stakeholders and increase overall participation is a valuable skill as well.
• What’s the incentive for being a guardian?
  Guardians are expected to remain on guard and vote frequently. They are compensated for this service with token rewards from the reserve. Beyond this hard incentive, as leaders among stakeholders, guardians often hold significant stake providing a soft incentive for the network’s well being.
• How many guardians are needed?
  The more guardians active in the network the better, but remember that we want them to be experts. Due to the amount of effort involved, it is reasonable to expect that at least in the early days of the network not many stakeholders will be committed enough to perform the task consistently. Creating experts is no easy task.

Continuous monitoring and due diligence is a lot to expect from a random stakeholder. Statistics show that engagement starts low. What can we do if we want the majority of stake to participate?

Delegators

Delegators represent the silent majority, those on the opposite side of the engagement spectrum. To attract them to participate, we must reduce product friction to the absolute minimum and lower our requirements from them.

Instead of frequent voting, we expect delegators the minimum of a single action — choosing a guardian to vote on their behalf.

• What skills are needed for being a good delegator?
  No special skills, anyone can do it. Delegators who want to do more will become guardians and will actively participate in the frequent voting. But delegators unwilling to do more can still participate. Delegation is a very simple and frictionless process, no special tools required. If you can operate a standard Ethereum wallet and use ERC20 tokens, you will be able to delegate.
• What’s the incentive for being a delegator?
  Every participation provides value to the network and no matter how small, still requires some effort. Therefore, delegators who go to the trouble of selecting a guardian will be given token rewards from the reserve. This reward is given only if their guardian actually votes on their behalf. This will encourage delegators to replace guardians which become inactive. The reward for delegators will naturally be lower than the reward for guardians in order to encourage the maximum level of participation.
• How many delegators are needed?
  As many as possible. If a stakeholder has a choice between not participating at all or becoming a delegator, we want them to become a delegator.

How everything fits together

Guardians are the representatives of stake. Every guardian must be active and is backed by delegators who chose them to vote on their behalf. Guardians vote using the stake they represent to choose the best validators. Validators do the heavy lifting of operating the network.

In summary, delegators choose guardians, guardians choose validators.

Parallels from a familiar world

There’s not much new under the sun. Proof-of-stake is a form of governance. We can draw many parallels between it and delegative representative democracy, a system that has evolved for two millennia.

Active participation in government is reserved for professionals, as it requires commitment and dedication. These professional politicians vote frequently on all matters of state and must be properly educated for the task. They are similar to guardians. They are chosen by the general public in infrequent low friction elections in attempt to drive participation by the general public to the maximum. The general public in this regard is similar to delegators.

Jump into the Orbs Universe

To get the full details about how the Orbs Universe PoS model works, jump on to the documentation.

Get involved with Orbs

• Visit the website to learn more about the Orbs public blockchain
• Orbs is open source! Review the code on Github and contribute
• Start developing apps on Orbs, review the documentation

Originally published at www.orbs.com on April 1, 2019.

The Orbs PoS Universe Archetypes — High Level Introduction was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The blockchain industry makes heavy use of buzzwords. Terms like “public” and “private” are thrown around but what do they actually mean? Is this the right way to define a blockchain? Does a private blockchain really exist? Maybe we should even take one step back and ask — what is a blockchain, actually?

The need for concrete definitions

How do you define blockchain?

This sounds like a funny question, but try asking it 10 different industry experts and you will probably get 10 different answers. Is there even one correct answer? Maybe the better question should be “what does blockchain mean for you?”

It is important for anyone working in this industry to attempt to answer this question for themselves. The hard part of defining buzzwords is avoiding the temptation to rely on a different set of buzzwords for the task. A good definition needs to be razor sharp. It needs to make things easily distinguishable. Anyone should be able to take your definition and easily distinguish whether something in question falls under the definition or not.

The dry technical definition of blockchain

When writing the Orbs position paper, I originally used a very dry and technical definition — ”blockchain is the technology of decentralized consensus“. Each of these terms can be defined separately. Decentralized systems are those who are not controlled by any single entity. Consensus is the process of several independent entities reaching a shared view of reality. The actual definitions were a bit longer, and one can refer to the original text for the specifics.

But there is a problem with this definition. The problem is that it does not cover the public aspects of blockchain. What is a public blockchain? Is there such a thing as a private blockchain? Many companies are building private blockchains, so naturally this concept exists.

To dig into these questions we should be asking ourselves something slightly different. What is the value in blockchain? What does this technology add to the world? What innovation can be accomplished with this technology that previously did not exist?

So, what is the value in blockchain?

We should be careful though not to be confused with the value of specific applications of blockchain. So far, the killer app of blockchain is digital assets — cryptocurrencies like Bitcoin that aren’t controlled by a centralized bank. It is easy to see the value in those. But this is not what we’re asking. We’re not asking about specific applications — we’re asking something deeper about the nature of this technology as a whole.

This is another question that is difficult to give a razor sharp answer to. People usually say things like collaboration — blockchain allows different entities to work together on solving a problem. They use terms like trustlessness — these different entities are not required to and probably shouldn’t trust each other.

I’m not satisfied with these answers because they are still not concrete enough.

Blockchain provides guarantees

From my perspective, blockchain begins with the subject of multi-player systems. A system provides a solution for some business need. A multi-player system is one that is used by multiple different and independent entities. This is a very broad field since almost every interesting system in the world has several different users.

Let’s take advertising as an example. An advertising system takes an advertiser, looking to promote something, and sets them up with a publisher, looking to rent real estate they own, where end-users will be exposed to said promotion. This system for example has three archetypes of independent entities, each composed of many different individuals.

Blockchain takes a multi-player system and provides a set of guarantees to the players in this system.

Exploring systems for multiple players

Before diving into the specifics of which guarantees are provided, we should point out that these multi-player systems are almost never operated by all players equally. Let’s explore this observation first.

For a system to work, it needs to be operated by someone. There could be a single operator or there could be multiple. Going back to our advertising example, a popular real-world example is Google AdWords (now Google Ads). It serves multiple entities but is operated by a single entity — Google Ltd.

The fact that we can have more than one operator isn’t yet the main innovation. The field of distributed systems is not new and has been in existence for several decades at least. The Internet, for example, is a communication system that is not operated by a single operator and was invented well before blockchain.

Almost every practical system would not be operated by all players equally. There could be many reasons why. For one, this would be terribly inefficient. The overhead cost of operation is usually proportional to the number of operators, so increasing it indefinitely is less than desirable. A different reason could simply be timing. Not every player starts using the system at the same time, so naturally the system had to operate before some of the newer players joined in. A different reason could be lack of interest. Operating the system requires effort that not all players are willing to spend.

If not all players are operating the system equally, let’s divide the players into two groups. Please forgive this coarse separation, we’re doing so for simplicity of the argument. The first group, which usually is the smaller one, we’ll call the group of “full” operators. This may not even be a group, it could be an individual. The second group will be everybody else.

Back to the guarantees

Blockchain technology provides every member of the group of non-operators with a set of guarantees. These guarantees would probably be articulated differently by different people, but I observe three distinct ones:

1. Auditability
   The rules of how the system operates, often called “the protocol”, must be known to every member of the group of non-operators. Every member is able at will to examine the output of the system and audit by themselves that these rules have been followed.
2. Forkability
   If a member of the group of non-operators is unhappy with how the system is operated, they can fork the system at any time. Forking the system means they can operate a new copy of the system that is identical to the original in any way up to the point of the fork. This means that all data and code required to operate the system are guaranteed to be available.
3. Governance
   Governance is the process by which decisions that change the rules of the system are made. Governance must be declared, meaning all players are shown the process by which rules can change. Governance is also enforced, meaning the mechanics of how rules change is guaranteed to work as declared.

I could have listed these guarantees without splitting players to operators and non-operators. These guarantees are naturally provided to every member of the operator group as well. The reason I have chosen to emphasize the group of non-operators is because this is where the innovation lies.

Systems that could have provided these guarantees to operators only are not particularly new and have existed before blockchain. The true innovation in blockchain is the ability to provide these guarantees to players that are (often willingly) outside the operator group.

How exactly blockchain provides these guarantees is outside the scope of this post, but will be focused on in a later post.

The value in these guarantees

A multi-player system does not have to provide any guarantees about anything. Let’s take our example of Google AdWords. Since Google Ltd. is the only operator, all players (advertisers, publishers and end-users) are members of the non-operator group. They are not able to audit the rules of how the system operates (for example, highest bid wins). They could not become operators. They could not fork the system because its code is proprietary and its database secret. Governance is not declared outside Google Ltd. being able to change any of the rules at any given time.

Every interesting system in the world serves multiple players. Practically none of these systems today provide any of these guarantees. These guarantees are simply not a necessity of life. The world can work just fine without them.

But, and here comes the big but — systems that will provide their users with these guarantees have an advantage over those that don’t. Providing these guarantees makes systems more competitive. All systems essentially compete over the group of non-operators — as they are considered the users of the system. With all other things being equal, users will always prefer to receive these guarantees than not receiving them.

Providing these guarantees does not come cheaply. This is why not every multi-player system in the world should run over blockchain. But as blockchain technology advances and becomes more efficient, this cost is lowered and more systems come to benefit from it.

How these guarantees make systems better

In a sense, the most important guarantee of the three is the second — the ability to fork. This guarantee represents beyond all others why giving these guarantees pushes us to design better systems.

If a system gives its users the freedom to leave at any time, yet these users choose to stay and the system remains popular, this system must be doing something right. Forkability provides a healthy environment of checks and balances. It allows systems to constantly evolve to their best possible form by enabling the right to exit.

As a developer, I see this behavior in action every day in the world of open source. Open source libraries encourage forks. Anyone can take TensorFlow, a leading framework for AI published by Google, and create their own improved fork. All the code is out there. The community would jump on that improved fork and use it instead if it proved to be more effective. The fact that the popular fork is still TensorFlow by Google shows that it is doing something right.

Public and private blockchains

And this brings us back to the debate of private and public. Personally, I don’t like the terms “public” and “private” because they are confusing. Is something public just because it is connected to the Internet? Is something private just because it isn’t?

The word public in the context of blockchain has a more profound meaning. The way I see public blockchain is by how the three guarantees are provided. Take forkability for example. I’m not familiar with a way to provide the group of non-operators with this guarantee without relying on external validators.

For me, the fact that these validators are external to the system and aren’t part of the operator group is the real underlying meaning behind the word public. The public part has more to do with the validators being public than the system itself.

So, if we refrain from adding the terms public and private, we are left with simply blockchain.

So what is a blockchain? We’ve circled back to our original question.

Blockchain is a technology that can provide systems with all three guarantees. Simple. If it is able to provide these guarantees, it is a blockchain. If it is unable to provide these guarantees, it isn’t.

Can blockchain provide value to a closed system?

Let’s take a theoretical system for example, I’ll use an extreme one to make a point.

Consider a country that by law has divided its cellular broadband frequencies between 5 mobile providers. This is legally a closed system, as there won’t be any more than these 5 companies participating. Since they are sharing bandwidth, these companies use a system to avoid collisions in frequency allocation. Only 4 companies desire to be system operators. The fifth company prefers not to be an operator but still uses the system.

Can blockchain provide such a closed system with value?

According to the definition above, the answer is yes. Since the fifth company is a member of the non-operator group, there is value in providing it with guarantees that would otherwise be given to operators only. These guarantees could not be provided without the innovation in blockchain.

Does the public essence of blockchain interfere with this system being closed? No. This system can remain closed, simply for lack of interest to anyone else, and still enjoy the value.

We need to be careful with closed systems though. It is too easy to miss out on the core value of blockchain in this scenario. It is easy to design a system that provides no hard guarantees. For example, relying on consensus algorithms like Raft that aren’t Byzantine fault tolerant. By definition — the inability to deal with Byzantine behavior undermines the guarantees we’ve been talking about. When this is the case and a system cannot deal with Byzantine behavior, we should not only avoid calling it private blockchain, we should avoid calling it blockchain at all.

Conclusion

So what is a blockchain — a technology that can provide multi-player systems with guarantees of auditability, forkability and governance.

How do we cope with the public/private debate? We move past the limitations of this overly simple rhetoric and focus on a given use case. Is there value in providing these guarantees under this use case? If so, using blockchain for this use case makes sense.

Get involved with Orbs

• Visit the website to learn more about the Orbs public blockchain
• Orbs is open source! Review the code on Github and contribute
• Start developing apps on Orbs, review the documentation

Originally published at www.orbs.com on March 29, 2019.

Defining the Public Blockchain was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s little argument that open source has transformed our world. As a developer, I cannot recall a single day in the last few years where I did not rely on open source software. I’m not the exception. The majority of software engineers today rely on open source daily in their professional lives.

For one, open source is dominating developer infrastructure. From operating systems (Linux in the cloud) to databases (MySQL, MongoDB, Redis) to programming languages themselves (JavaScript, Python, Java, C, PHP). It’s not just developers, it’s consumers as well. From what they run on their phones (Android) to how they access the web (Chrome, Firefox).

The motivation is clear. Open source is good for humanity. It is making technology more accessible and open — anyone can build anything.

Open source was not always mainstream

If you had asked a random developer 20 years ago whether this idea of open software would ever catch on, they would have laughed. Sharing intellectual property, your competitive advantage? absurd. Would it affect real business? barely, it’s a niche. The ones leading it? anarchists, trying to tear down establishments.

This is not very far from how many people view blockchain today. Decentralizing control when you can hold on to it? absurd. What is the business use-case? not mainstream, a niche. The ones leading it? anarchists, trying to tear down institutions.

With blockchain, it’s actually worse. The inflated cryptocurrency bubble and its recent recession, the abundance of opportunism and over-speculation, are all adding even more suspicion to the mix.

Open source and for-profit companies

In the beginning it seemed that open source and for-profit companies were mutually exclusive. Corporations like Microsoft were hailed as the enemies of open source. Companies saw code as their secret-sauce, which sharing would bring-about their downfall or destroy their competitive edge. Today, nothing is further from the truth.

The biggest contributors to open source today are for-profit enterprises like Microsoft, Google, IBM and Facebook. These companies are leading many of the most popular projects like React and TensorFlow. Personally, I was lucky to be part of such a company, Wix.com, and help take it from a walled-garden to number 11 in some obscure ranked list of global open source contributors in 2017.

Why are these companies choosing to open parts of their IP? Well, it’s certainly not because of ideology. Open source is making these companies more competitive.

A good example is Google with Android. Google was late to the coveted space of mobile already predominated by Apple with the transformative release of the iPhone. Microsoft was late as well (technically they were there first but with the wrong product), with more years of operating system domination than the other two combined. Penetrating this emerging market was no easy task.

Part of Google’s strategy was relying on a largely open source operating system, Android. Manufacturers like Samsung would have otherwise found it hard to join — basing critical parts of their business on an ecosystem they have zero control over would be unwise. This strategy paid off. The Android ecosystem grew as the open answer to Apple’s closed garden. Google did forgo the ability to sell licenses for this property, but gained something much more valuable: presence in the pockets of over a quarter of the population of Earth.

The same debate is taking place today about blockchain. Why would for-profit companies, market leaders especially, ever opt to decentralize any part of their business? Isn’t their position of power linked to centralized control?

I argue that they will do so for the same exact reason. Not because of ideology, but because it will make them more competitive. To maintain their positions of influence they will have to make ecosystems that are more open. Otherwise, their competitors will, and win.

Forks, control and the balance of power

We’ve seen why a company like Facebook would release IP like React — a project that transformed the way web frontend is built. What is less clear is why other companies would adopt Facebook’s native technology for their own critical-business paths.

I was fortunate to have had a front row seat to such a decision. When I was at Wix.com there was a debate on whether to base the Wix.com website editor on React. For a company that creates websites for a living, risking the editor is risking the lifeline of the company as a whole.

Imagine that one day Facebook decides to compete with Google for web domination and releases its own web browser as an alternative to Chrome. Significant parts of the web are based on React. What if, in this dystopian future, Facebook decides to make React incompatible with Chrome? This decision could jeopardize Wix.com’s business.

The governance of open source is successful mainly due to the concept of forks. Anyone can take the entire source code of any open source project and make a copy that they control, at the click of a button. If Facebook would ever make React incompatible with Google Chrome, Wix.com can fork React and create a version that is compatible. If the community favors this fork to the one Facebook is maintaining, they would adopt it. At some point, the more popular fork would actually become “the” React in the eyes of the public.

This delicate balance keeps Facebook in check. Facebook may maintain its position of influence as long as it doesn’t abuse it. Where does the line cross? where the consensus says it does.

This sounds awfully close to how blockchain governance works. This same guarantee of the ability to fork is one of the core guarantees this technology provides to its users. One thing to notice is that this guarantee is much stronger under blockchain. Beyond the source code of the system, you can fork all of its data as well.

A continuation of the open source movement

We’ve drawn several parallels between open source and blockchain. We’ve seen similar regard to both movements in their early days. We’ve seen similar motivations of openness. We’ve seen the same questions whether for-profit companies fit in. We’ve seen the same governance and balance of power.

I argue that it’s more than mere coincidence. I see Blockchain as a continuation of the open source movement, picking up where this left off.

There’s a clear limit to what can be shared with open source. Open source cannot open up live systems, it cannot open their data. You can share the source code for a server, but naturally you cannot share a running instance of this server.

Blockchain is making this next step technologically possible.

A concrete example

Let’s go back to Android. We’ve seen the value the ecosystem derives from having control of the operating system source code — this value allowed companies like Samsung to join in and made this ecosystem attractive.

But Android is not just source code. There are many living services required for the ecosystem to function. Android relies on push notifications, it relies on payments, it relies on apps being downloaded from Google Play. These services are all running instances, not just code. Billions of users query them daily. They hold data.

Who is running those services? Let’s focus on Google Play. With a name like that the answer is self evident. Google is running these services on private infrastructure that isn’t shared with anyone.

What is the cost of having Google in sole control of Google Play? For starters, a 30% fee every developer pays Google for the benefit of distributing their app digitally. But that’s just money. Every mobile developer has felt the uneasiness with the app approval process. Less fortunate ones have experienced app rejection and the 3 strike suspension policy. Absolute control of a distribution channel where said company’s own products are being sold and distributed can’t be good for competition. See what’s going on with Spotify in the Apple store.

What about competing app stores on Android? They’re possible, Amazon did a great job of building an alternative. Unfortunately these alternatives cannot resolve the fundamental problems and offer little differentiation.

Being able to run a service like Google Play together would provide a great value to the Android ecosystem. Such an idea is not technically possible with open source alone.

It is technically possible with blockchain though, I will be more than happy to show a proof of concept in one of my future posts. But let’s be honest, we won’t see this happening any time soon. A community run decentralized Google Play isn’t practical enough today primarily for business reasons.

Instead, I see a different opportunity. An opportunity for a for-profit giant like Microsoft, desperate to carve some niche in the mobile space. Building an app distribution channel that is not completely centralized. Giving a few more guarantees to the developers who are relying on it. Not because of ideology, but because it will make the offering more competitive — more competitive than Google Play and Amazon Appstore at least.

Blockchain will become mainstream

I believe that history will show that every system that has multiple parties relying on it will eventually have to provide its users with some hard guarantees. Not for ideology, but to remain competitive.

This doesn’t mean that every system will run on blockchain. Just like every piece of software doesn’t have to be open source. But there is some critical part of the world that has to be open. Just like some critical parts of software must be open source for companies to be successful.

Get involved with orbs.com

• Visit the website to learn more about the Orbs public blockchain
• Orbs is open source! Review the code on Github and contribute
• Start developing apps on Orbs, review the documentation

Originally published at www.orbs.com on March 26, 2019.

Blockchain as the Next Evolutionary Step of the Open Source Movement was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Watch the video:

Introducing the Orbs Contributor Series

Orbs is a decentralized public blockchain where open source plays a key part. Our goal is to expand the Orbs ecosystem as much as possible and onboard as many contributors to the project as possible. A truly decentralized project is one where any individual is able to contribute.

Making a project open source is not enough. Open source is more than mechanics, it’s about culture. This culture starts by open sourcing the Orbs protocol specifications, which enables every individual to understand the details of how the system works. It continues with open sourcing all of the reference implementations — we have one in Go language and one in TypeScript. It then continues by open sourcing the entire engineering management of the team to give full transparency as to what we’re working on — we do this with Taiga, a very cool project management tool optimized for open source.

Doing all of the above is not enough. We need to onboard external contributors the same way we onboard our internal core team. That’s why we decided to start sharing publicly some of the internal onboarding sessions we do. This is the “Orbs Contributor Series” — blog posts and video sessions to help onboard new Orbs contributors.

This session — Concurrency in Go Language

The latest reference implementation we’re working on is written in Go language. Go is designed for highly concurrent systems with lots of moving parts. Orbs is no different — as a decentralized and distributed network, the Orbs protocol relies on many asynchronous processes. In order to drive performance to its max, concurrency is utilized at the extreme.

This session is an introduction to concurrency patterns in Go and how we utilize them in the Orbs code base. The session assumes basic knowledge of the Go language syntax and basic familiarity with its concurrency primitives such as goroutines and channels.

Found this Interesting? Check out our projects on GitHub:

• orbs-network/orbs-network-go
• orbs-network/orbs-spec
• orbs-network/orbs-network-typescript
• orbs-network/lean-helix-go

Join the Orbs community:

• GitHub: https://github.com/orbs-network
• Telegram: https://t.me/orbs_network
• Twitter: https://twitter.com/orbs_network
• Reddit: https://www.reddit.com/r/ORBS_Network/
• Read the Orbs white papers: https://www.orbs.com/white-papers

Concurrency in Go Language — Orbs Contributor Series was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Working with Node.js, I’ve grown to rely on Lodash as an invaluable tool. It completes the JavaScript standard library with a set of handy functional operators over collections. I can’t recall a single JavaScript project I’ve worked on in recent years that hasn’t used it.

My experience of switching to Go has been very pleasant. Go resolves many of the issues I’ve had with Node.js over the years and yet remains as productive. I’ve been sorely missing one thing though — a library like Lodash.

What’s so great about Lodash?

JavaScript isn’t a purely functional language, and most of the code I write in JavaScript tends to be imperative. Nevertheless, some principles of functional programming (like chaining operators and immutability) come in very handy when working with collections.

Let’s say I have an array with some duplicates I want to remove. All it takes is one line with Lodash:

Let’s say that I only want to keep colors that have names that are longer than 4 letters. This takes one line as well:

And now assume I want to capitalize the first letter of every color… yep, not more than one line. I can even do all of the above together:

Lodash is probably the handiest tool for working with collections in JavaScript.

How would you do that in Go?

Let’s start with the first task: getting a unique slice. Googling for a best practice solution in Go yields this blog post as a first result. This is the code, credits to Kyle Banks:

You can imagine that if we had to filter and capitalize the first letter of every color as well, we would spend way too much time on the mechanics of these actions. This would be a bit exhausting. Where are my one liners?

Libraries to the rescue

Surely, there are some libraries that do these convenient collection actions for us. Surprisingly, there aren’t many popular ones in Go. Why is that?

To make such a library useful, it would have to support many types of collections. This is because you may have a slice of strings, a slice of integers, or a slice of structs. Supporting a generic type of slice isn’t straightforward in Go.

In most strictly typed languages, this is achieved with a language construct called generics. Unfortunately, Go doesn’t currently support it.

So how can we implement such a library without generics? The Go guru Rob Pike shows an example implementation of the function filter in this Github repo. Notice the heavy use of reflection. Indeed, it’s not difficult to expand this technique and implement the various Lodash utility methods. You can see an example project that tries to do exactly that here.

Why should we prefer to avoid reflection?

Reflection examines types in runtime. By working our way around Go’s lack of generics with reflection, we’re moving the heavy lifting of dealing with multiple collection types from compile time to run time.

Basic utility functions that work with collections should be efficient. I haven’t done proper benchmarking, but relying on reflection for such a common task feels plain wrong.

So, as a thought experiment, what can we do instead? Can we create a truly efficient implementation of Lodash in Go that will rival the plain old for loop approach performance-wise?

Compile time code generation

Generating code as part of the development toolchain isn’t a foreign concept in Go. It is used by the Protobuf compiler to generate Go access methods for protocol definitions. It has even been introduced as an official Go toolchain feature with go generate since version 1.4.

What if we wish to move the heavy lifting of dealing with generic collection types back to compile time? The best way to do this (currently) is to generate type-specific code for every one of the types we need in our project!

Consider the implementation from before of uniq over a string slice:

How would the implementation differ if we needed support for an int slice?

As you can see, it’s pretty much identical, except every occurrence of string has been replaced with int.

Can we do this automatically somehow?

Lodash in Go without reflection

Let’s design our API first. We can turn for inspiration to the original Lodash implementation in JavaScript. There, the library is used with the underscore character _. For example, _.uniq().

We can pay homage by keeping the same convention. The difference is that in our case, the underscore will be followed by a type. For example, _int.Uniq() for integers and _string.Uniq() for strings. We must specify the type explicitly since we’re going to get a completely new and dedicated implementation of the entire library for the specific type we need. This will guarantee that our runtime is as efficient as possible.

Usage is very straightforward. Just import the implementation you want:

There are dozens of potential types. Does that mean that our go-dash/slice library has to come with every single one? Not really, as this wouldn’t be practical. We’re going to generate the required implementations dynamically at compile time!

To achieve that, we’ll introduce an interesting command line tool: _gen, the code generator for our Lodash library implementation (notice how it starts with underscore as well).

When _gen is run in the source root of any project, it goes over all the source files in the project and looks for github.com/go-dash/slice/_TYPE imports. In the example above, it will find one for _string and one for _int. The generator will then generate an implementation for these specific types dynamically and add it to the library found in the Go workspace under the path$GOPATH/src/github.com/go-dash/slice.

The implementation of go-dash/slice on Github is actually very lean. It only contains a templated implementation for a single generic type. The code generator relies on this template to create the specific type implementations according to your requirements when you compile your project.

What about custom types?

Assume your project defines a custom complex type like Person:

It would be quite convenient if we could use our Lodash library on a Person slice as well. Well, this actually can work in the exact same way. Simply import an implementation of go-dash/slice that works on Person and the code generator will take care of the rest:

A working prototype

A working proof of concept of the go-dash/slice library, that provides several useful functions like uniq, filter and chain, is available on Github.

The project also includes a working command line generator.

The command line generator is conveniently installable on Mac via Homebrew: brew install go-dash/tools/gen

Going back to our first example: let’s say we have a slice of string color names which we want to keep unique and filter for colors with length longer than 4 letters. We can finally implement this in one line:

If you like this direction and want to come help port the rest of the useful Lodash functions to Go, please contribute.

Some final thoughts about syntax

The main thing that still bothers me with our chosen syntax is that we have an import per type. Is it possible to combine them somehow to a single implementation that will route to the correct place by type?

Consider the following:

This code combines all of the implementations into a unified Uniq that takes interface{}. While it doesn’t use reflection per se, it still has a two runtime dynamic casts and the switch which will affect performance. We should probably benchmark to see how much of an impact this adds. We should also probably benchmark the reflection implementation and see if our suspicion about runtime performance was indeed grounded in the first place.

Nevertheless, this was a fun thought experiment.

Tal is a founder at Orbs.com — a public blockchain infrastructure for large scale consumer applications with millions of users. To learn more and read the Orbs white papers click here. [Follow on Telegram, Twitter, Reddit]

Note: if you’re interested in blockchain — come contribute! Orbs is a fully open source project where anyone can participate.

The benefits of using Lodash in the Go language without reflection was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.