This Medium account is no longer active since July 2019.

You can now find the Orbs blog on the official Orbs website at the following link:

https://www.orbs.com/blog/

We Have Moved! was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Highlights

This segment was contributed by @OdedWx and @talkol

Hi community, this has been a busy month since the last R&D update!

The biggest thing happening was the first-ever rewards distribution. As you know, the rewards are given and accounted for on an ongoing basis (on every election), but the tokens themselves are distributed over Ethereum in bulk after 3 months. We’ve had our first successful distribution which included the first 27 election periods (1 through 27)!

Some statistics: 18,018,788 ORBS were distributed to 1,448 addresses. The distribution took place by a smart contract on Ethereum, to make sure we have a third party external verification of the entire process. There’s a very nice architecture that requires only a single transaction with commitments for the entire distribution event. Following the commitment transaction, any account may send the distribution transactions relying on the commitments. This means that the process is transparent and easy to review and also very efficient (50 distributions per transaction). See this post describing the entire process.

Another area the contributors have been focusing on this month is production network fixes. The network is up in production since March, and is constantly monitored for issues and improvements. For example, the lean helix threading model was improved, preventing corner cases that may cause a delay in a block creation. Another example is improvements to the gossip threading model.

There’s a lot of excitement in the community for working with the system and making this process easy for developers. One very exciting project I want to point out is the Orbs Playground — an online IDE for smart contract developers that lets them experiment and develop smart contracts on Orbs directly from their web browser — without downloading and installing any tools! This very cool tool started as a hackathon project, but got such a good feedback that it became a standalone project that is now actively maintained. Also look forward to seeing it embedded more in more in the various Orbs websites.

Blockchain Core

This segment was contributed by @IdoZilberberg

Last month marked the completion of the first release since the Orbs platform was launched in March. While several patches have already been released earlier, June signified the first full release with actual features.

Updates include improvements to Gamma, various stability and monitoring updates, design & implementation work on the Lean Helix consensus algorithm goroutine model and more.

@itamararjuan was working on a feature that intends to increase confidence against the introduction of bugs or regressions, and help measure improvement or degradation in performance, when changing the codebase.

This entails introducing a new step to the CI process, where, upon, the creation of a new pull-request on the orbs-network-go GitHub repo, provisions a new virtual chain (network) and runs the e2e (end-to-end) test suite against it.

@itamararjuan upgraded Nebula — Orbs’ node deployment tool — to support Terraform 0.12.

BTW, @itamararjuan also managed to complete a difficult bicycle tour of northern Italy during the same time, so great job and thank you :)

@ronnno and @electricmonk have been busy converting integrative tests that span Orbs and Ethereum into Javascript. Check out the results in the subrepo Psilo.

@ronnno wrote the contracts of rewards distribution, along with extensive testing.

The work is in PR110 and you can read more about it in this post. Also, thanks to @gilamran for adding rewards history to the Rewards page.

@ronnno and @IdoZilberberg have been modifying the goroutine model of the Lean Helix consensus algorithm of the Orbs platform. Presently, the algorithm suffers from less-than-ideal performance when the rate of incoming transactions is low, due to having a single goroutine for waiting for new transactions, and for handling external events such as Node Sync and Leader Election in Lean Helix. Following several proof-of-concept iterations, a new model was decided upon, and development is underway! This work is expected to complete during July, more details will be available in the next update (stay tuned).

@electricmonk completed an update of the Gossip goroutine threading model in PR1121. Before this change, DirectTransport had a goroutine per connection, and handling a message occurred on that goroutine. This effectively blocked further communication from that peer for the duration it takes to handle the message. Some Gossip consumers, such as the LeanHelix consensus algo, may block for a long time, if — for instance — it is waiting for a new block to be produced.

This PR creates a goroutine per Gossip topic, writing from the connection goroutines to the topic goroutines via a buffered channel. Essentially this serializes all messages from all peers to a single goroutine, but frees the connection goroutines to handle subsequent messages, and guarantees QoS per topic.

In addition, the code now creates a one-off goroutine per Block Sync request, so that scanning blocks or reading chunks from disk will not block the Block Sync topic goroutine. Another PR, #1193, upgrades the Orbs platform to compile using Golang 1.12.6 (previously 1.11.x was used).

It is expected that the Lean Helix topic will not be blocked, as it will have a goroutine that deals with reading from the topic.

@noambergIL and @IdoZilberberg updated code in PR49, PR1202 to support Sign() becoming an external service — to that end, a cancellable Go context was added as a parameter to this method.

More PRs by @noambergIL:

• PR1186 — To fix rewards & double delegate state
• PR99 — For election review created a script to show every election breakdown

More PRs by @ronnno:

• PR110, PR112 — Orbs Rewards distribution
• PR1188 — NodeSync test for when both petitioner and responder have no blocks
• PR95 — Preparatory refactor; part of the larger effort to convert integrative tests that span both Orbs and Ethereum to Javascript. To that end, @ronnno and @electricmonk created the subrepo Psilo.

Network Production

This segment was contributed by @jlevison

Rewards distribution

At the beginning of July, the first Orbs protocol rewards distribution occurred. Orbs has built a database to mirror Ethereum and run the calculations based on the raw delegation and stake data. You can check the token-bi repo on Github, more information about the distribution can be found at our blog.

You can read more about how Orbs Rewards are calculated in @Andrey’s recent post, “Orbs Rewards Distribution”.

Development

• Revamped the AWS roles in Nebula as part of an ongoing security review process.
• Published a list of the most important metrics for guardians, validators and app developers. Introduces two new metrics: transactions per second submitted to an individual virtual chain and queries per second served by an individual virtual chain per node.
• Created a library for notary apps, to enable building various solutions that rely on the notary core features of tracking information.
• Orbs core team invested some time into making sense of Libra.
• Explored a possibility of analytics contracts, when smart contracts method calls are being tracked and the information about the use of the main contract can be made available via a separate contract. This opens many roads to tracking, analytics, and an audit via dedicated contracts with a common standardized interface.

Use Cases and Dev Experience

This segment was contributed by @jlevison

Application Use Cases

There are multiple application use cases being developed across the community these days (that I’m aware of). These projects will be elaborated upon in dedicated blog posts as they mature, so here we’ll provide some basic descriptions and details:

• A POC with a leading academic institution regarding blockchain-based music rights management — this is a well-known pain in the industry, and we believe our Orbs-based solution can provide a valuable service. The developed POS combines on-chain rights registry with off-chain indexing and storage.
• A collection of use-cases with a media distributor to create a blockchain-based content registry (photos, videos etc.) and enable search, collaboration and monetization. Some interesting use-cases include:
• Smart contracts to register and search for registered images — including a perceptual hash search that finds images similar to provided ones
• Chrome extension — to highlight registered images in a browser and retrieve their metadata
• Webcrawler — retrieve metadata for all images on a webpage
• Document notarization — we’ve further developed the document notarization use-case, introducing encrypted fields, ownership and more. These concepts have been presented to multiple parties interested in blockchain-based document registration and notarization (https://github.com/orbs-network/notary).

Developer Experience

• Added ability to read smart contract debug logs via gamma-cli for development, more info documented at the following page in the contract SDK documentation.
• Expanded the packages available for smart contract development by whitelisting more of the available packages in Go, the full list is available here.
• Introduced experimental libraries for contract development available at https://github.com/orbs-network/contract-external-libraries-go
  Currently includes extending the state to natively store structs.

This is part of a larger SDK architecture change to enable experimental vs. stable, production-ready code, the team will expand on this subject and the rationale in a dedicated post.

• More documentation updates in regards to prism and the starter kit.

User Facing Products

This segment was contributed by @gilamran

Prism (Block Explorer)

• Added a new script to automatically upgrade prims’s version, and publish it (commit).
• Prism will now get published to docker hub on every push (experimental) and on every version upgrade.
• Added dbVersion to the db (commit), upgrading according to semver (commit)
• Introducing dbBuilder for first time/upgrade situations. (commit)

Hedron (Voting UI)

• Fully supports Japanese and Korean language translations (commit).
• Removed old JS/KO sites (using permanent redirect) (commit)
• Using a new rewards contract, it is now possible to view past rewards on the site (link)
• Fixed stake calculation bug (commit). Was showing the wrong percent.
• Better locale when displaying numbers. (Was send as string from the server) (commit)
• Proxy server is now in the process of deprecation, and all the web3 code is being extracted (commit) and will be moved soon to the client-web project.
• A big refactor to the client-web was done in order to separate Ethereum read/write services (with metamask and without). Commit.
• Removed unused contracts from the proxy server. (commit)

Playground (Online IDE)

The Orbs Playground is an online IDE for developers, a fast an easy way to tryout Orbs smart contract creation and debugging. Deploy a smart contract, execute functions and view events and state history. Available on http://playground.orbs.network for everyone.

Research and Architecture

This segment was contributed by @Avilanthe1

Orbs’ research efforts continue with researchers and developers work on different aspects of the Orbs blockchain infrastructure! Here is a breakdown:

PoS Research

Market research

Resources are dedicated to researching the PoS market. There are two sides to this market: Projects, and ecosystem players. On the projects’ side, Orbs researchers have been focused on learning ~20 different projects which have a PoS element to them. In particular, they’ve been trying to understand what goals were the projects trying to realize via specific design choices, and how ecosystem players eventually chose to respond. On the ecosystem players side, mapping the market to different types of players — staking services, infrastructure services, lending platforms, exchanges, etc to how each type may benefit/harm a PoS network.

Open and competitive validators nomination process.

Currently, Validators undergo a due diligence process in order to evaluate their technical abilities and enabling gradual rollout. Orbs architects are working on an architecture that enables to remove the need for due diligence and enables an open and competitive process. This competition, as a by-product, should increase the security of the network and its usability.

As a first step to achieve this, we are working on a locking contract for Validators and Validator candidates. This locking contract, deployed on Ethereum, is designed to match the Orbs election architecture and support efficient queries by the election contract that runs on top of the Orbs platform. In order to allow the protocol to evolve in the future, they’ve designed the contract to be migratable, while still requiring participants to provide their agreement for the migration.

Threshold BLS signature scheme security proof

An ongoing Random Beacon project is carried out by members of the research team. In this work, a set of rational players jointly perform a multiparty computation that results in a random number, that can be used in diverse applications. One such notable application is the selection of random committees in Orbs’ consensus mechanism.

A cryptographic primitive that naturally appears in this context, is ‘threshold digital signature’; the set of participants sign messages in an incorruptible manner as long as a large portion of them is honest. One manifestation of a threshold digital signature builds upon the well-known (single player) BLS signature scheme. However, security proof of the threshold version of this scheme is not covered in the literature. More specifically, the question raised is whether the devised scheme indeed holds the threshold property, meaning that a (certain specific) portion of players cannot produce a valid signature, while larger sets of players can. Orbs’ Research team has prepared a mathematical proof of security to ensure the security of the threshold version of the BLS signature scheme.

Zero-Knowledge

The Orbs core team continues to explore the subject of privacy through zero-knowledge proofs, focusing primarily on a few subjects:

• Trusted Setup. Most efficient forms of zero-knowledge proofs require a trusted setup, a subject of controversy, as it entails an expensive procedure and is specified to an application. In other words, different applications (including updates to an application) require different trusted setups. We study zero-knowledge proof systems where the trusted setup only has to be carried out once and is universal in the sense that it supports all applications. These usually come at a price of efficiency, and we focus on mitigating this problem, taking advantage of the efficiency of the Orbs blockchain infrastructure.
• Key generation ceremony. The generation of keys is a process ideally performed by a trusted party, as leakage of the private keys has severe implications. However, In typical blockchain usually, such a party does not exist. Our team has been studying the procedure to ensure that keys do not leak while avoiding the need for a trusted third party.

File Systems and Immutable Large Data Storage

Orbs Network aims for accommodating apps that (among others) require large amounts of storage. After all, how would you run a distributed YouTube if storage is limited? One direction the research team has taken to explore immutable storage for large data.

Part of the research included the reviewing of the IPFS (InterPlanetary File System) protocol. IPFS is a distributed peer to peer storage system that has recently gained a lot of interest from various blockchain projects that see IPFS as a good candidate for their protocol’s storage layer (like TrueBit).

The research team has been scrutinizing the different components of IPFS in order to learn from them towards a solution tailored particularly for the purpose of the Orbs blockchain infrastructure.

Among these components are Distributed Hash Tables (DHTs) for fast content lookup and peer locating the network; GIT protocol for version control; block exchange protocol for data swapping marketplace — all may be relevant for the future design of the ever-evolving Orbs infrastructure.

A prominent piece that is missing in the original design of IPFS is the incentive layer. When considering distributed storage solutions at scale, with recurrent data reads and writes, there must be an incentive layer that allows nodes to withstand their costs. The FileCoin protocol is designed to complement exactly that. The research team has recently focused on one of FileCoin’s most interesting innovations: Proof-of-Replication (PoRep). PoRep provides an entity with a way to prove that a specific number of replications of a particular file are stored in her local storage system. A distributed file system protocol that is able to absorb the overhead PoRep incurs can solve the problem of data availability, which is one of the major issues when dealing with vast amounts of storage.

Thanks for reading! I hope this recurring monthly segment is educational and does a great job informing Orbs followers on the R&D happenings. If something is unclear, or you wish to comment or otherwise participate in the open-source Orbs project, join the Orbs Community on Discourse or email us directly :). Also, be sure to check out the links below for more information.

Till next time,

Ciao

❤

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 July 18, 2019.

Orbs R&D Update July 2019 was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockchain is a young business, too young for us to have seen any project fully develop. If we look around, we see how inflationary models benefit projects in their infancy. But this observation will not remain once these projects grow out of their infancy.

For bootstrapping a good blockchain platform, having a good protocol and implementation is not enough. A key element in the success of a decentralized system is having different and independent groups use it, operate it and govern it. Designing an economic incentives mechanism to incentivize such participation by all these different groups is a big part of the work related to launching a blockchain platform.

How to take off, how to cruise

It’s important to distinguish between incentives that can get a platform “off the ground” and what’s needed for it to sustain in the long run.

When starting from zero, none of the participants can expect to benefit from any normal course of business: The value generated is just not sufficient to sustain any economic activity, and surely there’s not enough to go around. The only asset a blockchain platform has at this point — and in fact, the same may apply to any product that is launching for the first time — is its growth potential and the benefits of joining early on what could become a success.

There are many ways the promise of future success can be used to promote participation: Sell shares of future success to investors and pay participants (or at least subsidize their service) to lure them in; distribute shares in the future success to the early participants; have an “early mover advantage” in place so participants can hope to enjoy the fruits of their seniority; and more. And though there are different ways to achieve this, the principle is one: Participants allocate value (either plainly by providing funding or in the form of putting in the effort, time or their reputations) and expect to gain benefits, financial or otherwise, if the platform takes off.

Of course, this cannot apply in the long run, when the growth potential has been exhausted. Just like other products, blockchain platforms that reached their “cruise altitude” must have a sustainable model. In a sustainable model, the total value gained from the platform surpasses its total operating costs and the parties gaining that value are sharing enough of their gains with the parties bearing the cost to make the operation beneficial.

Outside of blockchain, this can be seen with tech start-ups who raise venture funding and subsidize their services to gain market share, starting to monetize only after growing enough to ensure their market dominance. In the public blockchain space, no platform has yet reached that point. Even Bitcoin, the first blockchain platform, is still in its early growth stages, and is heavily subsidized: for example, in the past 3 months miners gained about 3,850 BTC from mining fees and 164,450 BTC from block rewards. In other words, block rewards paid for 97.5% of the mining cost. Block rewards are simply subsidies transferred from the pockets of early purchasers (whose BTC is worth slightly less due to inflation) to the pockets of miners. The purchasers, of course, are happy to subsidize Bitcoin use, because they expect it to enable wider adoption of the protocol and increased demand for the BTC they hold.

Long-term Strategy

It may sound as if creating an economic model that works during takeoff is the harder part of the problem: it involves estimating the future value of assets, including intangible assets such as experience, brand, seniority and so on. But in fact, takeoff models have been tried in the hundreds, and by observing which blockchain projects created a high-quality community of operators we can assess what works in the existing economic models. The long-term sustainability of an economic model is, on the other hand, mostly uncharted territory.

There are, though, two types of stakeholders we can profile: the token holders and the platform users (app developers).

Who are the token holders and what do they want?

Token holders in platforms that are taking off are a very diverse group that is quite hard to define. But the future is much simpler: When the platform has matured and its growth is completed, utility tokens’ use is just as their name suggests — to pay for a utility (for that matter, the utility can be for paying fees, staking, voting, etc). Naturally, those holding the token, are doing so only because they intend to use it in the future, or used it in the past. They don’t expect to get rewarded for holding it, and they surely don’t expect to be diluted for subsidizing someone else’s use of the network.

What platform users want

The needs of the app developers are actually easy to predict. When all the hype dissolves, we can expect to see that consumers using blockchain-based apps aren’t willing to pay more than — or experience a product inferior to — its centralized competitor. The watermark for the platform is cloud: centralized apps using cloud platforms have the best tools to create a great product in predictably low costs. Decentralized apps that compete with them must be able to offer similar quality at roughly the same costs.

Note that it’s not enough to have low fees in the present. If the network economics don’t make sense, the fees may be low now but skyrocket when there’s actual demand for the platform. This is the case with many of today’s public blockchain platforms. The economics of cloud services is aimed towards the exact opposite: in almost all services, users expect to pay less as they grow, and for all costs to decline over time — in proportion to ever-declining hardware costs.

Our full analysis of what blockchain platforms need to do in order to win in the bigger competition with centralized ones is now on our website.

My conclusion

I firmly believe that inflationary models and perpetual rewards models are unsustainable. In designing the economy of the Orbs platform, we focused mostly on making sure the users can expect to have low and predictable fees in the long term, so they don’t have to worry about changing their chosen platform as they begin to grow fast. Economic models need to be determined early on and are extremely hard to change at later stages, so getting the fundamentals right in the first time is critical. I’d be happy to answer questions or see comments on our models in our discussion board.

Inflation on the Orbs platform

Accordingly, the ORBS token which drives the Orbs platform is non-inflationary. All tokens have been pre-mined and the supply is fixed (at 10 billion tokens).

Funds needed for bootstrapping the platform in its early years, such as token rewards in the Proof-of-Stake model, do not come from inflation — unlike many PoS projects. Instead, the source of funds for token rewards is a pre-allocated and limited reserve pool (55% of the total supply, vested over 55 months from TDE).

For the detailed breakdown of the ORBS token distribution, please take a look here.

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 June 24, 2019.

A Sustainable Token Economy Cannot Be Inflationary was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the previous post, we’ve discussed how to write and deploy a smart contract on the Orbs Network. This part will be devoted to writing a front-end application, and interaction with the contract via orbs-client-sdk in JavaScript.

Scaffolding the app

For a quick and easy start-up, we will use React and the create-react-app to generate a new application.

Our application will contain only 3 components:

• App — Higher-order component which will contain the state and the business login of our application
• Messages — Presentational component that will render list of messages, and
• MessageInput — Presentational component with </textarea> for composing a new message.

We would also need orbs-client-sdk to communicate with Orbs. It's an SDK that provides basic functionality like creating an account, querying and sending transactions, etc. For more documentation check out this repo.

We install it via npm: npm install orbs-client-sdk.

Creating a user

Every chat application requires a user to post any message. We also need an account in order to communicate with the contract. For the purpose of our application, we will create an account per user in case one doesn’t exist yet.

Orbs-client-sdk has a method for that:

Sender is an object with 3 fields: publicKey, privateKey and address. These fields uniquely identify our user. In order to avoid the generation of a new account every time the user enters the app, we will store it in the localStorage. Important! Storing privateKey in the localStorage is for demonstration purposes ONLY. Do not do this in the production environment.

Creating an SDK instance

Besides the user account, we need an instance object of orbs-client-sdk for our app to function.

We can create it by calling a constructor function:

The constructor of the client receives 3 parameters:

We will use this instance in the future for querying node and sending transaction.

Sending a message

Now, when we have an account, we can start adding messages. Fetching first won’t show us anything, so we’ll need to add some:

MessageInput component renders a simple TextArea with the submit button. It gets a prop “onSend”, but its logic is implemented in the app. Then a user hits the Submit button or Enter, the callback is invoked passing the message as a parameter.

The more interesting part is sending a message to the contract. Let’s take a look.

Firstly, we need to create a transaction:

Transaction is like a write-to database, which is why we also need to pass our public and private key in order to sign the transaction. We specify the contract by its name and the method that we want to invoke (sendMessageToChannel in our case). Lastly, we pass the array of arguments that will be passed to the specified method during invocation.

Since the contract is implemented in Go language and it has different types from JavaScript, orbs-client-sdk provides utility function (e.g. argString) to normalize types between different languages.

With the transaction object in our hands, we can actually send it:

const response = await orbsClient.sendTransaction(tx);

At the end we can verify the response by reading transaction status and execution result. If the values are “COMMITTED” and “SUCCESS”, then out transaction has been executed successfully.

Fetching messages

In the previous part, we’ve been able to send the message. Now let’s try to display them in a live manner. We will start with just fetching the first batch, say, first 50 messages. Then we will improve the solution by using pagination and polling for live updates.

Fetching the first batch

Similar to sending a message, we start with creating a query. It’s different from transaction, because we are doing a read action and it doesn’t require the consensus between nodes. Therefore it’s much faster:

In order to create a query, we are calling the corresponding method of the orbs client and passing our public key, contract name and the method that we would like to invoke on the specified contract. Lastly, we pass the array of arguments, very similar to what we’ve seen in createTransaction. In our case we specify the channel name and range of messages, say we want to get the first 5 messages.

When we send the query, we should expect the array of messages in return in JSON format.

We have the Messages component whose purpose is to render the list of messages. As soon as get a response from our query and update the state of the App component, messages will be rendered on the page.

There are two flaws with our current implementation — when a user sends a new message, we need to refresh the page in order to see it; when we have more than 5 messages, we won’t see them too. We can solve it with pagination and polling mechanism.

Pagination

Pagination, in a nutshell, is a mechanism of fetching only chunks of data instead of fetching all at once for a better performance.

The method ‘getMessageForChannel’ supports from and to arguments that allows us to specify the chunk of messages that we want. We start with the first message, and going to fetch 5 messages every time.

As soon as we get a response, we update the value of the message cursor with the amount of messages received and append new messages to the ones that we loaded previously:

Polling

Now let’s address the problem with live updates. There are 3 possible solutions in the front-end world to this problem: polling, long-polling and web sockets. We will use the simplest of them — polling.

It means we will call our fetchMessages function at a constant rate to query the contract:

During the mount of our application, we firstly call fetchMessage to get the first batch and then we call setInterval. JavaScript event loop will invoke our fetch function at the given refresh rate. Thus, every 2 seconds we fetch a new batch and if it contains new messages, our state will be updated and messages are rendered.

Deploying the app

Our application is ready. It’s time to deploy it and see it live in production. Create-react-app supports the generation of a static website and deploying it to github pages. Follow this guide to enable it for your application.

You can see the Conversation application running live here.

Conclusion

In these two parts ( Part I) we’ve discussed how to build a simple decentralized application end-to-end using Orbs platform. The full working code is available in this GitHub repository. Feel free to fork and improve it.

Sergey (@bolshchikov) is a passionate software engineer and manager who loves to solve complex problems. He previously worked as an engineering manager and developer at Wix.com and co-founded the biggest front-end conference in the Middle East — “YouGottaLoveFrontend”. Sergey holds an MSc in Industrial Engineering from the Technion.

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 June 17, 2019.

Guide to Apps on the Orbs Network, Part II: Writing a Front-End Part was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Orbs network was launched and opened to public participation at the end of March 2019 alongside the distribution of the ORBS token to private sale purchasers. The following report highlights the main developments in the Orbs Proof-of-Stake (PoS) ecosystem based on accumulated data for the first six weeks.

Main findings:

• Community analysis: Organic Guardian growth and education led to increased community interest in participating in securing the network through staking
• Product contribution from third parties increases with community interests, spearheaded by Guardians

The Orbs core team is excited that so many participants have already joined the Orbs community and begun making crucial contributions to the security, operation, and development of the Orbs network.

Disclaimer — the data that serves as the basis for the findings of this report was gathered from various sources, as noted throughout the document. Naturally, due to the pseudonymous nature of the Ethereum blockchain, there is definitely some potential margin of error in conducting such analysis.

Community interest

Delegated stake growth over time

In the Orbs Universe, the Delegators assign their voting power to the Guardians, who, in turn, participate in Validator election on their behalf (DPoS). Growing delegated stake shows increasing interest in participating in the Orbs ecosystem:

Acquired stake (from Exchanges) and delegation over time

We are witnessing a growing interest in acquiring ORBS tokens on exchanges for the purpose of delegating them to participate in the Orbs Universe.

This analysis is based on collecting known addresses of cryptocurrency exchanges from various online sources (Etherscan, Bloxy) and employing basic heuristics on address activities. The tokens retrieved from exchanges that changed their delegation status were identified.

The following graph shows the percentage of the delegated stake of tokens acquired on exchanges:

Based on our findings we can see that significant amounts of ORBS tokens acquired and retrieved from exchanges are delegated and participate in the Orbs PoS ecosystem. We believe this shows growing community education and interest, with a focus on long-term participation in the network (as opposed to speculation).

Increasing Decentralization

Decentralization of token holdings in public blockchain is critical to the health and sustainability of the network. Decentralization increases network security by reducing the risk of collusion between participating parties. For example, a more even distribution of stake between a growing number of token holders reduces the risk of a small number of token holders having too much of an influence over the network and creating a cartel. Similarly, a growing number of Guardians, with an evener voting weight distribution between them, increases the confidence of ecosystem participants that a small group of Guardians won’t be able to collude and take over the network governance.

70% of Delegation over time

In the current PoS model, Guardians vote frequently to exclude misbehaving Validators from the network. A Validator that was voted out by 70% of the participating vote over a course of 3 election cycles will be removed from the Validators list.

The diagram below indicates how many different addresses hold the top 70% of delegated ORBS tokens, which means the minimal number of Delegators needed to reach the threshold of 70% of delegated stake in order to vote out a Validator:

We see a growing distribution of the delegated stake, thus increasing the decentralization.

80% of ORBS float holders over time

In addition to the delegated stake, we also analyzed the distribution of ORBS token holdings. A significant portion of ORBS tokens is being held at exchanges (see above), which obscure the number of holders and their stakes. Thus, for this analysis, we focused on ORBS holdings out of exchanges.

The metric we chose is how many different addresses hold 80% of ORBS tokens in circulation, which we measured over time:

We see that over time the holdings are distributed between more and more parties — currently, over 600 addresses hold 80% of ORBS float.

Guardian activity

Guardian growth over time

The initial number of community organizers indicates the commitment of large private sale holders to the network long-term. The later growths show an increased organic interest for creating new communities around the Orbs PoS Universe:

Guardian weight change over time

Guardians are soliciting appointments from Delegators to vote on their behalf in Validators elections. An interesting metric of decentralization is the Guardian voting weight over time relative to the overall voting weight.

The following chart shows that the voting power of Guardians becomes more evenly distributed over time:

Guardian organization

The Guardians have a central role in the Orbs Universe. They monitor the performance of the Validators to vote out misbehaving ones, and they also organize the Delegator communities and represent their interest.

Since the Orbs network launch, Guardians have developed tools to educate the Delegators and further ease the delegation process, translated Orbs material to various languages, created new communication channels and, perhaps most important, diligently participated in the voting process.

Some examples of Guardians activities:

Paradigm Citadel

Paradigm Fund is a Moscow-based technology fund, engaging in deep research of blockchain technology projects and participating accordingly. They researched the Orbs project, (team, technology etc.) and chose the Orbs project over alternatives. They are among Orbs Universe Guardians and have created tools to grow the ecosystem, such as website templates for new Guardians, Guardians communication channel and delegation scheduler.

D.VA Group

A Korean crypto group engaged in multiple activities in the blockchain space. They are among the Orbs Universe Guardians and have developed a Telegram-based delegation bot, which makes it very easy for Delegators to delegate and get information and updates about Orbs.

Technological interest

Orbs is an open source project with over 70 repositories publicly available on GitHub under the MIT license. An important indication of a project’s success is the level of technological engagement by the community in the development of various modules, components, and tools to enable a more versatile, robust and easier operation of the entire ecosystem.

We already see technical interest both from Validators, who aim to make Orbs node operation smoother and cheaper and from Guardians, who develop tools for the community.

Validators adaptations

The reference implementation provided by Orbs includes tools to deploy the Orbs Validator node on AWS. Several Validators expressed interest in further developing the tools to support node operation on their own infrastructure.

One Validator operates several data-centers around the world and has developed and implemented a toolchain to deploy the Orbs node on a bare-metal server.

Another Validator developed an alternative deployment procedure to deploy the Orbs node on any server and is planning on sharing the solution with the other Validators to provide an alternative deployment option reducing operational costs.

Both intend to share their developed tools and procedures with the community.

Summary

Orbs is a growing project that has already garnered significant interest and participation in its ecosystem in the first six-weeks since launch. We find growing participation both from Delegators, who hold and acquire ORBS to participate in the PoS model and from Guardians and Validators, who join the ecosystem and create tools to improve it.

Liked this update? Join the discussion on the community board thread!

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 June 13, 2019.

Orbs Universe: The First Six Weeks was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

At the beginning of July 2019, the first Orbs rewards distribution will occur! The following post describes the various rewards, how they are calculated and the distribution process:

The Orbs network launched on March 28th, 2019. The Orbs network relies on all of the participants in the proof of stake ecosystem to provide for the security and operation of the network. There are 17 active Guardians currently registered and 14 Validators running in production. There are now over 1300 Delegators participating in the Orbs PoS ecosystem.

At the beginning of July 2019, the first rewards distribution will occur. This post describes the various rewards, how they are calculated and the distribution process.

Reward Types

Rewards are accumulated following every election cycle. There are 3 types of rewards: Participation Rewards, Guardian Excellency Rewards, and Validator Rewards.

Active Guardians are eligible for Delegator rewards for their own stake.

It is important to note that the same address can be eligible for all 3 types of rewards, i.e. a Validator can serve as a Guardian, and also receive self-delegation rewards.

The accumulated rewards for a specific address are available here:
https://orbs-network.github.io/voting/reward

Participation Rewards (Delegators and Guardians)

Token holders that delegate their voting weight to an active Guardian directly or indirectly, are rewarded proportionally to their stake. In order to receive the delegation reward for an election term, Delegators must have delegated to a Guardian that participated in the election.

An annual aggregate sum of 60M ORBS tokens is allocated to reward participation (of Delegators or Guardians). The reward allocation per election term is determined as a fraction of the annual allocation proportional to the duration of the election term.

Participants are rewarded in proportion to the stake they own and delegate at the time of each election event. The rewards are calculated at the end of each election term. The reward allocated to any specific Participant at any specific election term shall be capped to such Participant’s delegated stake for that election term multiplied by 8% divided by the annual number of election periods (for detailed calculation, see “Rewards calculation” section below).

Guardian Excellency Rewards

Guardians enforce the security of the network and are rewarded for their own stake as part of the participation reward (described in the previous section). In order to encourage Guardian participation, top-ranking Guardians are also rewarded with the Guardians Excellence Program.

An annual aggregate sum of 40M Orbs is allocated to reward top-ranking Guardians for their work. The reward allocation per election term is determined as a fraction of the annual allocation proportional to the duration of the election term.

In each election term, rewards will be allotted to the 10 leading Guardians that actively participated in the elections, ranked by the amount of stake delegated to them (including their own stake) in that election. The Guardian Excellency reward is distributed to Guardians in the top 10 group (in proportion to that stake). The rewards are calculated at the end of each election term. The reward allocated to any specific Guardian at any specific election term shall be capped to such Guardian’s total delegated stake for that election term multiplied by 10% divided by the annual number of election periods (for detailed calculation, see “Rewards calculation” section below).

Validator Rewards

Validators are rewarded for running the network protocol and the actual steps they take to keep the network active and secure. The Validators rewards comprise:

• 4% annual rate of the Validator own stake. Awarded for the duration the Validator was elected
• Fees paid by any applications which may run on Orbs, divided equally between the active Validators
• Validator Introduction Program — 1M ORBS tokens per Validator, on an annualized basis. Awarded in proportion to the duration the Validator was elected, for the duration of the Validator Introduction Program.

Rewards Distribution Process

• Rewards will be distributed at the beginning of July (exact schedule to follow).
• The rewards will be pushed to the recipients’ addresses on Ethereum.
• The rewards will comprise the accumulated rewards for each address (for all its relevant roles), up until (and including) the 27th elections, which will be based on Ethereum block number 8048900, which will occur at the end of June (https://etherscan.io/block/countdown/8048900)

Rewards calculation

The rewards calculation is available in the “Orbs PoS Ecosystem” document ( https://www.orbs.com/proof-of-stake-ecosystem/). The calculations will be published in parallel with the actual rewards distribution so that anyone can retrieve the relevant information from the Ethereum network and confirm the calculations.

An example of calculated rewards for the 19th election cycle is available here. Note — these rewards are just for the 19th election cycle, NOT the total accumulated rewards.

The actual calculations

For elections and rewards calculation purposes, only whole ORBS tokens are considered:

• For example, for a Delegator stake of 15,240.13 ORBS the participating stake is 15,240 ORBS
• This “whole ORBS only” approach is carried throughout all calculations

Number of election periods in a year = 117.23

• This calculation is based on the original blockheight progression on the Ethereum network
• Elections occur every 20,000 Ethereum blocks

Per election Validator reward = validator_stake * (4%/num_periods) + (1M / num_periods)

• At this point, there are no application fees on the network

Per election Guardian Excellency reward = top10_guardian_reward_ratio * guardian_total_voting_power

• Where top10_guardian_reward_ratio = MIN(10%,(40M / sum_of_top10_guardians_total_voting_power)) / num_periods
• This reward is for the Top 10 (by their total voting power) of the Guardians who voted in this election round

Per election Participation reward = delegator_reward_ratio * delegator_stake

• Where delegator_reward_ratio = MIN(8%,(60M / all_participating_stake))/num_periods

Reward calculation fixes

Lately, one of the Guardians notified the core team regarding an issue with rewards calculations. The core team has researched the issue and discovered a bug (an incorrect spec implementation) in the reward calculation contract. This bug caused a miscount for a small number of delegations, affecting 29 participating addresses, to the total sum of 89,668 ORBS (less than 0.5% of the projected total rewards for the first 3 months).

A fix for this issue was approved and deployed by the Validators.

The affected participants will be compensated manually by Orbs sending them the difference, after the general rewards distribution.

Click to view the list of affected addresses.

Summary

The upcoming rewards distribution marks a milestone in the Orbs network journey. We are all excited to see what’s next for Orbs and look forward to the entire ecosystem working together to make the Orbs vision a reality!

PLEASE NOTE: RECEIPT OF REWARDS OR OTHER VALUE, AS WELL AS ANY USE OF THE ORBS NETWORK OR ACTIVITY THEREON, IS SUBJECT TO THE ORBS NETWORK TERMS OF USE, WHICH ARE AVAILABLE AT https://github.com/orbs-network/orbs-spec/blob/master/NETWORK-TOU.md , INCLUDING, WITHOUT LIMITATION, ANY TERMS AND CONDITIONS THEREOF PERTAINING TO TAX CONSEQUENCES, WITHHOLDING OBLIGATIONS AND/OR TAX INDEMNIFICATION.

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 June 12, 2019.

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

Introduction

We believe that the development of blockchain technologies is going to change the way developers write applications as we know today. Orbs is a part of this massive effort by existing as a public platform, open to anyone. These two articles (Parts I & II) will demonstrate how to build a fully working chat application using Orbs platform.

In general, decentralized applications consists of two parts: A smart contract which stores information, and a client-side that communicates with it via sdk. In Part I, we will describe how to write a simple smart contract on the Orbs network, test it, and finally to deploy it.

Part II is devoted to writing a simple client-side application using React. I will demonstrate how to use orbs-client-sdk to query smart contract and send a transaction written under consensus.

Prerequisites

Before we start, you will need the following tools installed on your machine:

Docker is used to run Orbs smart contracts locally. NodeJS and npm are used to write client-side application that will communicate with the smart contract.

Part 1: Writing, testing & deploying an Orbs smart contract

Anatomy of a simple smart contract

Writing contracts for Orbs is very simple. Currently, it supports Go language only, which uses a basic syntax familiar enough to most programmers without prior knowledge.

Let’s look at the sample contract that increments a counter and returns its current value:

A contract consists of two exported functions — add and get. They will be available to be called from a client application. We reveal them by defining a global variable PUBLIC.

System function (_init) is called by the system only once when the contract is deployed. This function is not part of the public interface.

Orbs-contract-sdk

Contract SDK allows developers of smart contracts to interact with the Orbs platform. There is plenty of documentation about it in the gitbook, so we won’t discuss it in too much detail right now.

What is important for us in this tutorial is the ability to set and read state. State is a simple map between key and its value. In the example above, we create a counter and update its value on add operation. The initial value is 0 as defined in _init() function. Add function reads the current value in the state and adds the amount which has been passed to the function.

Running locally with Gamma-cli

When we have a contract, we execute it by running it on a local server.

Orbs provides its own toolchain (similar to Ganache for Ethereum) for running a simulated blockchain environment. It is called Gamma-cli, and is available here: https://github.com/orbs-network/gamma-cli.

On Mac, you can install it with a single command (you need to have Docker installed for gamma to run):

brew install orbs-network/devtools/gamma-cli

You can start it with gamma-cli start-local and stop with gamma-cli stop-local. After restart, all the data will be lost.

Then you can deploy the contract similar to the command below:

gamma-cli deploy Counter.go -name counter -signer user1

Our first real contract

Now that we have covered the prerequisite knowledge, we can begin developing the contract for our chat application.

In the spirit of test-driven development, we will start with an end-to-end test that will help us flesh out our API in the process.

First, we should be able to add new messages to the chat and get a message ID in return:

This e2e test completes the first part of the flow — putting information into the system. A simple contract that could achieve that goal would be something like this:

Since our state is a key-value store, and we need to invent our own way to emulate a list of messages per channel. The easiest way to do that is to keep a counter of messages per channel and then simply increment it when we add a new key (`m_testChannel_1` will store content of the message, while `count_testChannel` will store the number of messages of `testChannel`).

After seeing that the e2e passes, we can modify the contract a little bit to store some more data, such as timestamp, sender, and block height.

Now we can focus on adding another crucial part of any chat app; retrieving the list of messages. We will update our e2e a bit to flesh out the behavior we want: Add a single message, then ask for a list of messages with ids between 1 and 10.

Why do we even need JSON? Orbs platform doesn’t yet support more complex values like arrays or structures (great opportunity for a pull request btw 😉)

JSON is a standard way of serialization and deserialization of data in JavaScript, and is supported by any major platform. We will use JSON and expect to get a response like this: [{ID: 1, Message: "hello, world!"}].

Inside the contract, we will define the new struct for serialization and the contract method to return the result of serialization as a string:

You can see the final version of the contract at the project git repo.

Deploying contract to Orbs node

The only thing is left — deploy it. Based on the configuration of gamma-cli environment, you can specify the targeted environment — local or mainnet. More about it here:

gamma-cli deploy contract.go -name Conversation

Conclusion

This is it! We’ve reached the end of Part I. Here we described how to create, test and deploy a smart contract on Orbs platform. On the next part (Part II) we will describe how to write a simple web client that is able to interact with our contract.

Feel free to dive into code of the app in the git repo or even play with the app itself.

Kirill is leading a cloud infrastructure effort at Orbs. He’s very passionate about his cats and the deepest lore of the Dark Souls series. Kirill’s Github.

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 June 11, 2019.

Complete Guide to Writing an Application on the Orbs Network (Part I of II) was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

At the Hexa Foundation, our focus is using blockchain for social impact. One example of this impact is using the technology to create a platform that will help countries and refugees alike. According to the UN Refugee Agency (UNHCR), by the end of 2017, there were 71.4m refugees worldwide, compared to 21.1m at the end of 2005. This crisis is a major concern for governments and NGOs alike, not only from a humanitarian perspective but also from economic and geopolitical perspectives. Recent refugee crises, such as the ones in Syria (6.3M), Afghanistan (2.6M), South Sudan (2.4M), Myanmar (1.2M), and Somalia (1.0M) have gained public attention calling governments to respond. The United States is facing unprecedented numbers of migrants from Central America. This past April close to 99,000 people crossed the southwest border of Texas. This has resulted in a crisis situation whereby the government is overwhelmed and unable to even process the number of migrants crossing at their point of entry.

This global refugee crisis encapsulates the following key challenges:

• Difficulties in tracking and sharing refugee migration data among governments and NGOs — an issue for example since governments and aid organizations do not always know which country the refugee has entered before arriving in their jurisdiction, or if/from whom they have received aid prior to entering the country
• Lack of valid identity documents (IDs) of refugees — this leads to the inability to track aid funds, and also the inability to help refugees function within their society

There are global initiatives led by the UN, such as Migration Data Portal and Global Compact for Migration (GCM), and the Internal Displacement Monitoring Center (IDMC). Both of these initiatives are collecting data in order to build a global database to help tackle the crisis. However, while the former is still in its very early stages, the latter focuses on internally displaced persons only, not on the broader definition of refugees (refugees, asylum-seekers, internally displaced persons, returnees, or stateless persons). Still, we believe that both platforms’ main hindrance is that they are both centralized systems. As such, aid organizations are not incentivized to share information. This results in a fragmented solution in which each organization only trusts itself, and the overall aid is far from optimal. What if a blockchain-based solution could tackle the challenges mentioned above and provide a transparent infrastructure that governments and NGOs alike could easily adopt and share? Imagine a biometric platform deployed as a permissioned/consortium blockchain, meaning that there are certain restrictions on joining as a node and accessing data, in order to tackle privacy concerns. The nodes may be national immigration services, border checkpoints or aid organizations. They will be the ones that carry out the enrollment and identification process, including writing new identities on the blockchain as a proof of registration and authentication. The nodes are also users on the blockchain, meaning that they interact with the refugee in the form of transactions. The proposed platform would entail the following steps for refugees declaring themselves at a border checkpoint:

1. Enrollment — regardless of whether the person obtains an official ID or not, she enrolls in the biometric identity platform, i.e. a new biometric ID is generated on the spot along with a cryptographic wallet. This wallet stores the new ID and all other relevant metadata, e.g. location, time, additional documents provided by the refugee, relatives, etc.
2. Identification — once the biometric ID is available, the checkpoint tries to identify the individual, to verify whether there are no other matching IDs on the ledger
3. Data transmission — the individual makes her first transaction on the blockchain, in which she sends all that info to the checkpoint. The data is encrypted so that only both sides can read it. All other nodes will only be able to verify that there has been a transaction between user X to node Y at time Z. They know where node Y is located, and they are able to extract from this transaction the cryptographic digest of the biometric identity. This allows them to look for a match when they generate a new biometric identity for a refugee

Once all three steps are done, the refugee may be referred to the next steps of the “standard” procedure, according to the receiving state’s immigration policy. There are many benefits to this platform, stemming from core features of blockchain:

• Efficient end-to-end process
• Refugees get a new immutable digital ID proving their existence and documenting their asylum request
• Multi-purpose new ID with immediate use and additional uses down the road, e.g. cryptographic wallet
• Secure platform providing refugees with the maximal level of privacy
• Information is easily shared only among nodes on border checkpoints and humanitarian aid organizations. Therefore, in special situations, e.g. locating lost family members, the process is fast, simple and easy location of lost family members at the receiving state
• Each checkpoint can easily track the number of refugees it has assisted. In that manner, national immigration services can easily aggregate accurate data from all checkpoints, in real-time
• Receiving states and aid organizations can better track and monitor refugees influx and improve cooperation

The most basic feature of this platform concerns the access level to individuals’ private data. Obviously, privacy is a difficult subject to navigate, however, It could be argued that it is only reasonable that once an individual arrives at a checkpoint asking for asylum, that checkpoint (and the immigration service that it represents) is entitled to maintain full access to her personal data. Furthermore, in order to provide the refugee the opportunity for a fresh start at the receiving state, it has to hold her biometric identifying data, as it does for its residents. Still, checkpoints from other countries are most definitely not entitled to access that data, for privacy considerations. They will only gain access to the “public” data, i.e. individuals’ arrival at different checkpoints (nodes) at certain times. Modern cryptography is fully capable of providing this kind of data access differentiation. This suggested platform will run over a permissioned blockchain, in which nodes must be approved prior to joining the network. Only government agencies or recognized aid organizations could become nodes, thus making sure that private information does not fall into the wrong hands. On the transaction level, the data is encrypted and can only be accessed using a private key, which is held by the individual only. This means that nodes have full info only on the transactions ( i.e. refugees) that they were part of. Consequently, each checkpoint does not know the identities of refugees who went through a neighboring checkpoint, they only know that they were there. This solution prevents data breaches, as even if someone manages to imposter as a legitimate node, all they get access to is a ledger of encrypted transactions. The data is encrypted by so many different entities, and each has access to only a small portion of it.

Of all the potential positives that blockchain can enable, improving the efficiency of government-related services is among the most prominent. A blockchain-based global database could be a forward thinking and innovative approach towards helping the global effort to manage the refugee crisis. It has great potential to aid multiple governments, while also making the day to day lives of documented and undocumented refugees logistically more comfortable. Furthermore, this platform can be a key strategic element to solving a global humanitarian problem and improving the lives of the weakest individuals in our society. It may not be perfect, but as they say: the enemy of the good is the perfect. At the Hexa Foundation, our aim is to use blockchain technology to create social impact.

To learn more visit www.hexa.org

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 June 4, 2019.

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

Case Study

Target audience: Validator DevOps, Orbs contributors and anyone interested in log analysis of the Orbs platform

As new software meets the real world in production for the first time, unforeseen issues pop up. Anyone in the business long enough knows this for a fact.

Orbs platform is no different, and while considerable effort was, and still is being expended to retain the highest code quality, post-production incidents do happen, but they provide opportunities to make the software better yet.

Part of improving software and keep learning from experience is creating case studies such as this one.

This post includes technical notes to help you, the reader, make sense of the information you are seeing. It is not an exhaustive description of Lean Helix or any other service of the Orbs platform. For that, visit the Orbs Spec.

Such was the case that a few weeks post-launch, the Orbs core team observed less than optimal behavior of the Lean Helix consensus algorithm in production. The dashboard showed that frequently, a block passes consensus only on the third attempt, instead of the expected first or second attempt. This meant it took longer to reach consensus and consequently transaction requests took longer to return a result to the caller.

Technical note: Before going into more detail, let’s understand a bit how Lean Helix works (with gross oversimplification):

• Choose a Leader node at random
• The leader collects pending transactions (i.e. transactions sent by clients and still waiting to be included in a block) into a “proposed block”
• The leader suggests this block to the other non-leader nodes
• The non-leader nodes try to reach an agreement (a.k.a consensus) by passing around messages of various types (more on that later) relating to the content of the proposed block. There is a time limit as to how long this can take to propose the block and reach an agreement. If the time limit is exceeded and consensus has still not been reached, a new leader is chosen among the non-leader nodes (the previous leader itself becomes a non-leader node) and the process repeats itself.

The above flow is called a View. The first iteration (view) is denoted V=0, the following iteration (with a new leader) is V=1 and so on. The time limit per View is exponentially increased for every View. For V=0 the leader has 4 seconds to reach consensus (production configuration as of May 2019) before it is replaced. For V=1 the next leader has 8 seconds, for V=2 the next leader has 16 seconds and so on. When consensus on a block is reached, every node commits the proposed (now accepted) block, the View is reset to V=0 and the process repeats itself. Read more about Lean Helix: Orbs’ Unified Theory of Randomness: Explaining the Helix Consensus Algorithm

Now, given the production configuration, it was expected that the first leader at V=0 will sometimes be able to reach consensus, but mostly the second leader at V=1 will do that (exactly why is out of scope). There was no apparent reason to reach the third leader at V=2 unless there was some considerable network lag.

Having said all that, here you can see the problem:

Instead of having all nodes report they are either on V=0 or V=1, the frequency of V=2 was quite high.

So, we started digging deeper.

It was clear that a specific node (let’s call it Node A, its actual identity is irrelevant to this case study) as exhibiting the majority of V=2 incidents.

At this point, the dashboard could not provide further clues. Suffice to say that one of the Orbs core team’s monitoring goals is to improve on what can be easily identified in the context of the dashboard and postpone the following costly log research to more complex issues.

In this case, logs were the next step.

From a troubleshooting perspective, we were fortunate to have frequent V=2 incidents so it was easy to obtain fresh logs around the timeframe of such incidents. It can be quite frustrating trying to debug a rare issue for which logs are not readily available.

The logs use the node’s Orbs address for filtering. In node A’s case, it is “0123456789abcdef”, sometimes contracted to “012345”.

Since we did see Node A’s block height advancing we knew it was up to date on the blocks.

Now, when a node does not commit a block through the consensus algorithm, it can still receive new blocks via Block Sync.

Technical note: Block Sync is a service within the node that wakes up after some predetermined time during which no new block was committed. The node assumes that it’s being left behind for whatever reason, so it requests newer blocks from other nodes in the network. This is useful in case the node was down for a while and now needs to sync to the rest of the network. It is also useful in this case, where blocks are not being committed as part of the consensus algorithm. Read more about Block Sync in Orbs Spec: Block Sync in Orbs Spec

We suspected that node A was advancing through Block Sync rather than through consensus.

So, the initial filter was to show blocks being committed as part of the consensus algorithm flow.

Analyzing logs is like looking at the data with various lenses, one at a time, each of which captures only a subset. For logs over some size, there is simply too much data for a human to grasp in one go.

Here is the first screenshot from logz.io. In it you can see positive filters (in blue), negative filters (in red) and a search string (logz.io uses the Lucene query format):

The PHASE COMMITTED message means the block was committed as part of the consensus algorithm.

We noticed the lack of node=”012345″ (a shortened version of the node address) — it’s not there, nor before or after this time.

This made us assume that no blocks are committed as part of consensus at all, on node A. To make sure this assumption is correct, we made another search that confirmed that node A only receives blocks via Block Sync. It shows that every block of Node A was received via Block Sync, no exceptions. See the messages “successfully committed block received via sync”:

As a sanity check, we checked which additional nodes receive this message (that is, don’t commit blocks through consensus algorithm). We found out that other nodes occasionally also receive blocks via Block Sync. It’s ok for this to happen from time to time, but node A showed this for 100% of the blocks.

At this point, we established that Node A fails to reach consensus 100% of the time, so it was time to dig into Lean Helix consensus algorithm’s logs to follow Node A’s flow through it and understand what goes wrong.

We now focus only on Lean Helix logs to narrow the investigation. All Lean Helix logs have a property called lhlib which is set to true, so it is easy to filter for only these messages by adding a condition that lhlib property exists — see below:

Let’s focus on a specific block that Node A had to receive from Block Sync, but other nodes managed to commit with consensus: 454927. We obtained this block number from the screenshot with “successfully committed block via sync” messages above. Notice the search string “H=454927” in the screenshot below:

We can see that consensus messages are being ignored (such as the outlined COMMIT message in the screenshot above) by Node A, because “PREPREPARE is not stored” (same as “not received at all” for our purposes). To understand what this log message means, here is another technical note:

When the leader node proposes a block to the other nodes, it does so by broadcasting a PREPREPARE message that contains the block, to the other nodes. Then the other nodes “debate” with one another whether they agree on the proposed block or not, by passing around more message types, such as PREPARE and COMMIT (no need to discuss those here). PREPREPARE is the initial message sent by the leader and contains the proposed block itself. If it was not received by some other node, that other node will refuse to receive any other subsequent consensus messages related to that block, because there is no point in participating in consensus if the node doesn’t have the proposed block, to begin with.

Next, it was time to understand why PREPREPARE was not received by Node A.

Yet another technical note: As we said, the leader of the first view (V=0) sends out a PREPREPARE message that contains the proposed block. Now, if the leader fails to reach a consensus within the time limit, it is replaced by another leader, now at V=1. Here is a twist: usually, that new leader of V=1 will utilize the same block proposed by the previous leader (cheaper than creating a new block itself). It will send the reused block to the other nodes within a NEW_VIEW message. That NEW_VIEW message contains within it the previous leader’s PREPREPARE message along with the reused block (essentially the new leader says: “Hey, the last leader’s proposed block was valid, we just didn’t manage to agree in time so let’s try again”)

Next, it was time to search for where Node A actually received a PREPREPARE (if it did at all) from the leader and find out what went wrong with it.
Turns out Node A did receive PREPREPARE from the leader.

Here it is, let’s break this screenshot down:

At 16:05:23.988, a NEW_VIEW message is received by Node A from the leader of V=1 (sender=”ff33c7″). As explained in the last technical note, this is expected. The next thing that should happen is for Node A to unpack the internal PREPREPARE message, and from it, to unpack the block and validate it.

NEW_VIEW was unpacked and its contained PREPREPARE was also unpacked (it’s just not logged), however the attempt to validate the contained block fails, due to the block’s timestamp. This is weird! no other node failed to validate this block.

Let’s understand the outlined error message:

currentTimestamp=159df14e0fab5b36 translates to May 12 2019 13:06:03 (with the help of a hex → decimal calculator and this site that converts millis since Epoch to ISO8601 time string). prevTimestamp=159df14bde5aed90 translates to May 12 2019 13:05:54. So far so good — the current block’s timestamp is later than the previous block’s timestamp, which makes sense.

Next, we see: now 2019–05–12 13:05:23.989402103.

This does not make sense! how can “now” on the machine be earlier by 40 seconds than the current block’s time? later on that line, you can see the tolerance between “now” and the block’s timestamp is 30 seconds ( jitter 30s) and because the difference is larger (40s), validation fails, and all of the above results from it.

Note: This error message is admittedly confusing and has already been made human-readable as a result of this investigation.

At this point we were nearly convinced this is a machine clock error on Node A as this code works correctly on all other nodes.

After contacting node A’s IT, they indeed identified a 29 second time drift on the machine’s clock, and promptly fixed it.

A few minutes after they fixed the machine’s clock time, we took these screenshots:

The above screenshot shows the V=2 symptom is gone. To be on the safe side, the screenshot below shows node A managed to participate in consensus and commit a block, thus no longer relying on Block Sync.

Some conclusions:

1. Write case studies such as this one, for the benefit of the community so the Orbs core team thought processes can be shared and discussed.
2. Improve dashboard so problems can be understood from graphs and gauges, to postpone costly log analysis
3. Specifically to this case study — add graph and alert against node time drift.
4. Improve logs as an iterative process

The purpose of this post was to shed some light on the troubleshooting Orbs platform issues along with technical notes on some internal workings.

Obviously having detailed knowledge of the system makes this process easier, but reading dashboard graphs and filtering through logs is a generally useful skill that can be applied to any monitored system.

Thanks to Ron Bresler for helping out in proofing this post!

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 June 3, 2019.

Troubleshooting the Orbs Platform | Case Study — Orbs was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last week in the Tel Aviv offices, Orbs’ core team conducted its very first Hackathon! Within just two days of brainstorming, coding and eating junk, the teams developed the very first real-use apps on the Orbs network.

Aside from the obvious value derived from the new apps themselves, the goal of the hackathon was to put the network to real-world usage tests. What’s a better way to know how to improve the network than to use it ourselves? After all, if it’s not good enough for the core team, it’s not good enough for the general community of developers.

First, Orbs engineers met up to brainstorm logistics and use-cases they wanted to explore. After the session which resulted in 16 well-rounded ideas), and a celebratory breakfast, they split up into teams and got to work on a full belly. After 48 hours, the developers were asked to stop coding and gather in a showroom to present their projects to a panel of judges.

The presentations were fun and educational, but more importantly, they demonstrated just how much can be accomplished in a mere 2 days even in separate teams. It’s become clear that with more time, and increased collaboration, the potential for Orbs Network is amazing.

Here are the judges’ favorite 4 apps developed and presented during the Hackathon:

Digital ID

View source

The goal of this team was to prove specific properties about identity (e.g. being a senior citizen, having a driver’s license, having a college degree) without having to present an ID card/driver’s license, which discloses the full ID.

An Issuer (such as Ministry of Internal Affairs) performs KYC on the user and signs the ID which contains all properties.

This signature is publicly verifiable. Zero-knowledge proofs are the mechanism that allows verification of specific property without revealing any other properties.

Every verification of this property Blockchain allows for a trusted third party arbitration, thus guaranteeing fairness.

How is this use-case applicable to the real world? Take as an example: The situation where this product can allow senior citizens to purchase discounted public transport tickets without having to disclose their identity, only the property of “senior citizen”.

Anti-Scalping Ticketing System

View source

A scalping resistant ticketing system for large scale sporting events and music concerts. The system balances conflicting needs:

• Privacy
• Free transfer of purchased tickets
• Scalping resistance

Competing event organizers and venues trust-less sharing of ticket purchase history to intelligently detect scalping attempts before tickets are sold. Optional ID sampling at the gate provides a second control against illicit tickets trade. Ticket transferring mechanism requires high trust between transferring parties to discourage trade.

Voting App

View source

Current voting systems are not reliable, and vote tampering is, unfortunately, a lingering concern.

Decentralized voting allows an authority to ask a group of chosen voters a question on any subject and prove that the votes are counted properly.

The potential usage are endless. The simple example from the open source world can be a vote whether a certain feature should be merged into the project. If the proposal collects the minimum required of votes, then the code is merged.

Online IDE

View source

Orbs platform allows writing smart contracts in Go language. The development experience is bearable but it could be improved. The team decided to tackle the task by creating an online IDE where any developer can write code and execute it remotely right from the browser. This ability allows to provide valuable insights about the contract such its current state, visible event logs, and execute its methods:

Retrospection

The most important part of the hackathon was the presentation and conclusions stage; an hour of debriefing giving contributors the opportunity to talk about their development pain-points and the potential improvements that they would like added to the platform. It turned out to be quite a long list, one that would have taken a long time to curate if not for this group exercise (see image).

Some of the major improvement suggestions became obvious, such as scaffolding for a smart contract project, richer support of data structures in smart contracts, improved debugging capabilities, monitoring, and more.

HUGE thanks to all who posted their ideas to the Orbs Community board in the days leading up to the special day! We are looking forward in anticipation to the next Orbs hackathon, and hope to involve the global developing community to partake in this fun, productive event :)

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 May 30, 2019.

Insights into Orbs’ R&D Hackathon was originally published in The Orbs Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.