5 years ago
Highlights: Ver 1.2.2 released ⁂ New Staking scheme research complete ⁂ New stress & endurance testing suite ⁂ New Reputation feature ⁂ New demos and status pages ⁂ More developers contributing
···
There were many changes, and improvements happening since the last tech update, so once again, we are happy to give you an overview of some of the things we achieved during this time.
One significant related effort is the creation of Marvin, a new stress testing and endurance testing suite that will alert and help identify cases where code changes lead to performance degradations.
An important aspect of the network is its liveness, and we've added an internal metric of the liveness of validators. The metric, very basically, checks how many times a validator failed to close a block. Such failure can be because he was malicious or simply because he experienced a brief network outage. If the number of consecutive failures increases, it will hurt the node's "reputation. This value can help guardians to make an informed decision about voting out nodes that impair the liveness of the entire network. Speaking of reputation, read below about the new status page, that shows the status of live validators.
In case you didn't notice, the Orbs team released and the validators accepted version 1.2.2 of Orbs network in October, featuring time-based elections, triggers, and the reputation mechanism just mentioned.
You may have noticed in the past company updates, our continued efforts in driving real-world usage to our platform. Below you'll read about many developments related to the user side of the system, a new demo page that includes links to several demos you can quickly and easily try yourself, and many more.
Another important effort that was made by the research team is to finalize the new staking scheme and enable the utilization of a Management Chain functionality. You can read below the details as well as some of the design decisions that were made during their development.
Finally, two new developers started contributing to our code, and below you'll be able to read more details about their contributions so far, as well as the details of the things highlighted above and many, many more updates.
···
This segment was contributed by @IdoZilberberg, @electricmonk:
@IdoZilberberg & @itamararjuan - work is underway on Marvin, the test framework for Orbs' test networks. Marvin identifies performance degradation or increases in errors when merging PRs into the master branch. This prevents regression in production code. It does so by running stress and endurance tests against a test network and comparing present and past results.
Summarized test results are sent to the developer, along with comparison to existing master branch. In addition, full test results are accessible via Grafana dashboard or directly in the Prometheus TSDB (Time Series database). Prometheus continuously collects metrics from the main test network that runs the master branch. In phase II it will gain the ability to run on every push to an open PR for more immediate developer feedback, and will be able to test the effect of pushing PRs to master prior to actually doing so, preventing unwanted merges. It will also collect logs into an ELK stack for deeper analysis.
An initial version of the client that exercises the test network is already written in Go, and the two additional Node.js processes are underway. These are (1) the Orchestrator that listens to external requests (such as from CircleCI) and spawns JobExecutor instances per test job, and (2) the JobExecutor that runs multiple instances of the Go clients. The full code is available on the Marvin repo.
Running stress tests against testnet yields a notification to Slack, such as this one:
(Disclaimer: This is still in development, the results will be more detailed, will compare against previous runs, and will be aggregated from more transactions over a longer time period.)
Here is Grafana sample output (not related to the Slack message above):
Reputation & Committee Generation
This new feature allows every Orbs-node to save information about the behavior of the validators. The node keeps track of how many times in a row a validator failed to close a block. When a validator doesn't close a block, we will make it less likely for it to be the leader of the block committee - this helps the liveliness of the network. Soon this information would be present to the guardians, so they may choose to vote against misbehaving validators.
https://github.com/orbs-network/orbs-network-go/pull/1299
https://github.com/orbs-network/orbs-network-go/pull/1297
https://github.com/orbs-network/orbs-network-go/pull/1296
Orbs-nodes can support four new types of arguments in public methods of the contract (methods that can be called from the client directly): bool, *big.Int, [20]byte & [32]byte. This expands our usability of contracts.
This addition required modifications in several repositories, listed below. It's already part of the coming gamma-cli 0.9.0 version, where it can be tested and used in the experimental mode.
memuffers
https://github.com/orbs-network/membuffers/pull/33
https://github.com/orbs-network/membuffers/pull/36
https://github.com/orbs-network/membuffers/pull/37
Orbs-spec
https://github.com/orbs-network/orbs-spec/pull/186
https://github.com/orbs-network/orbs-spec/pull/184
orbs-network-go
https://github.com/orbs-network/orbs-network-go/pull/1405 - sanitation of packages to allow math/big
https://github.com/orbs-network/orbs-network-go/pull/1398 - types of bool and *big.Int
https://github.com/orbs-network/orbs-network-go/pull/1356 - types [20]byte & [32]byte
orbs-client-sdk-go
https://github.com/orbs-network/orbs-client-sdk-go/pull/30
orsb-client-sdk-javascript
https://github.com/orbs-network/orbs-client-sdk-javascript/pull/28
Gamma-cli
https://github.com/orbs-network/gamma-cli/pull/11
Amir is a prolific open source contributor who is starting to contribute to the ORBS network code and documentation:
https://github.com/orbs-network/orbs-network-go/pull/1389
https://github.com/orbs-network/orbs-network-go/pull/1397
https://github.com/orbs-network/orbs-network-go/pull/1411
https://github.com/orbs-network/orbs-network-go/pull/1419
@vistra is another strong developer who started to contribute to the ORBS codebase. Here are some of the changes he contributed recently:
···
This segment was contributed by @jlevison
SFBW19:
The Orbs network was updated to version 1.2.2 in October and was accepted by the Orbs network validators.. The release notes are available here: https://github.com/orbs-network/orbs-network-go/releases/tag/v1.2.2
···
This segment was contributed by @Avilanthe1
The R&D activities on Orbs PoS architecture were focused on the Orbs staking contract.
The staking contract development was completed and is now undergoing an external security audit. The contract is available for review in the orbs-staking-contract GitHub repo along with a high-level specification.
The Orbs network staking contract is set to be deployed on Ethereum similarly to the ORBS native token. The use of an ERC20 token and a staking contract on the Ethereum blockchain enables the Orbs PoS hybrid model. In the Orbs PoS model, the staking, delegation and validators selection process are done on Ethereum and the Orbs network calculates the election results along with the earned rewards based on the data logged on Ethereum.
The staking contract enables Orbs token holders to stake tokens, request to unstake them, entering a cooldown period and withdraw tokens back to their ORBS ERC20 account.
An interesting aspect of the Orbs staking contract is the migration strategy. First and foremost, the contract is designed to be immutable such that stakers’ funds are secured and one can not move staked tokens or modify the staking properties without the staker approval. On the other hand, we want to allow stakers to transition to new staking contracts in the future without requiring them to first unstake before staking in a new contract, leaving them without staked tokens for the cooldown period. The proposed staking contract addresses the issue by allowing stakers to explicitly request to migrate their stake to a new staking contract thus allowing a seamless transition.
A complementary product for the staking contract is a staking wallet to enable a simpler interface for staking. A staking wallet allows ORBS token holders to interact with the contract without a need to manually construct the transactions. We’ve designed a product definition for such a staking wallet and are starting to develop it. The staking wallet we’re working on may be used by the Orbs community as a reference implementation for additional wallet implementations..
Gad has completed the specs of two new features: the Management Chain and the Ethereum Proxy.
In addition to the benefits coming from the introduction of the Management Chain (see more in the previous tech update), its inclusion obliges supplementing the Orbs network’s infrastructure with cross-Virtual Chain (VC) communication. Communication between different VCs will be regularly used between any VC and the Management Chain but can be employed for other uses such as the design pattern of hierarchical VCs. The management chain will hold every VC’s configuration, for example, the current VC’s validators set. This, in turn, will facilitate coordination between validators assigned to operate a new VC. However, it also implies that the VC is no longer standalone. To audit a VC (and verify its state transitions), one must consume the VC’s configuration from the management chain.
The Ethereum Proxy feature will significantly facilitate the process of obtaining and calculating the Election results from Ethereum. Among its benefits is the removal of the external agent that mirrors the Ethereum data and relaxation of demands from an Ethereum node. Now, an Ethereum node needs only to support state queries for the latest 100 blocks rather than 5000 blocks as it formerly used to be.
···
Everything we develop is, as always, updated in our GitHub repositories. Here, we try to point to the things that are actually done and ready to be used, rather than discuss ongoing developments and future plans.
Just like in previous updates, and as part of being true to our goal to develop enterprise-class software, we continuously labor to improve ORBS' stability. Most of it is done by improving our tests, code cleanup, and refactoring, whenever we encounter or even suspect any sort of instability or general code smell.
Be sure to follow Orbs' channels to stay up-to-date with all the latest dev! Till next time,
Ciao!
We use cookies to ensure that we give you the best experience on our website. By continuing to use our site, you accept our cookie policy.
