5 years ago
After a year and a half of building the Orbs blockchain from the ground up with the most talented team I could hope for, mainnet was released to the public on March 28th. One of my non-technical post-launch goals is to focus on communicating directly all the work we’re doing.
Brace yourselves - this is long :)
···
Since the launch of the production-ready Orbs platform and its release to the community, the Orbs core development team has continued to monitor its progress and work to develop improvements to propose to the community of participants in the Orbs network. Our team prepared a post describing what we’ve learned so far, the problems the network has encountered and the fixes we’ve proposed to the Validators running the protocol.
There’s been a lot of interest among Orbs contributors to implement cool use-cases on top of the platform to show what it’s capable of. Some of these ideas will remain proof of concepts, while others may eventually mature to working products as an increasing number of companies in the ecosystem express interest to take them to the next level. The Orbs core development team believes that the focus of this exploration should be to work on the use-cases that have the potential to derive the most significant utility from a public blockchain, mainly by benefiting from the various guarantees Tal (@talkol) writes about (auditability, forkability, governance). See here [link] Some of the use-cases the Orbs core development team believes have this type of potential are the following:
Node.js Package Manager (NPM) is a super popular tool for sharing code between projects in the JavaScript ecosystem. It hosts over 1.2M packages that are downloaded over 1B times per day. This database is open-source but what’s interesting is that it’s completely centralized and managed by a well-known company called npm Inc.
Currently, it fulfills two important roles: 1) authority and 2) storage.
Firstly, npm Inc. authenticates users who can publish new versions of packages and manages their permissions. Secondly, it hosts and maintains the registry where packages are stored.
Sergey (@bolshchikov), one of the core contributors, is a die-hard JavaScript ecosystem fan, incepted proof of concept of a decentralized npm can address both roles by utilizing smart contracts and public blockchain.
A smart contract allows the decentralized npm to easily manage the authority and role of every user publishing code in a transparent manner. It also makes it possible to store and audit the metadata of packages that are being published.
Kirill (@netoneko) created Conversation (https://github.com/orbs-network/conversation) - a serverless chat running on top of the Orbs blockchain. It utilizes the strength of Orbs where finality is achieved in sub-seconds and you can actually have a responsive chat on top of the blockchain!
Got an idea for a useful apps to develop using Orbs? Suggest it on the community board!
···
During April we’ve worked a lot on monitoring and stabilizing Orbs network:
Gamma is a local environment that enables developers to develop, deploy and test on Orbs layer. You can read about it here and start playing with it here.
Orbs Ethereum Contracts Github
This monorepo contains projects involving Orbs and Ethereum interoperability features. During the development of V1 the Orbs team started experiencing the challenges involved in testing, building, and deploying features that span across more than one blockchain.
All subrepos contain Solidity contracts for deployment on Ethereum. Some contain Orbs contracts, and some contain additional standalone processes meant to facilitate communications between the two networks. In addition, some subrepos include off-chain apps such as web UI.
The stack used in these repositories is diverse:
The monorepo currently contains 3 + 1 subrepos:
When V1 was released, each of the subrepos had a different internal structure, following different conventions. In addition, the directory structure was confusing since the repository was not initially conceived as a monorepo. The refactor/cleanup included:
In the weeks leading up to our planned launch, the Orbs core team ran stability tests on various network configurations. The purpose was twofold: identify bugs that manifest themselves only after the system has been online for a long time, and test the load limits of the system.
As a new software system goes to Production it is essential to have a monitoring system in place. Its main goal is to identify anomalies, that is, deviations from the KPIs that have been set for the system. This information should optimally be presented in a clear format so that a casual glance at a performance dashboard lets users identify an "All OK" or "Not all OK" status.
Prism is a reference implementation of an Orbs block explorer. Just like every part of Orbs, Prism is an open source project. If you want to review the code or contribute, take a look here:
https://github.com/orbs-network/prism
Boyar is probably the only blockchain provisioning system today to do dynamic resource allocation in real-time. This means that when a new virtual chain is created, new containers are automatically spawned on all Orbs nodes by this system (an Orbs node is a cluster of machines, not a single machine).
Nebula is an Orbs node deployment tool for validators that provisions all the needed resources on AWS and creates the Orbs node.
Since the latest update, Nebula will not create an Ethereum node anymore as part of the Orbs node. From now on, it’s the validator’s own responsibility to set up an Ethereum node in a separate process (prior to creating the Orbs node using Nebula) and ensure it is synced and ready to hit the road before using Nebula to deploy their Orbs node. Since the Orbs POS ecosystem is based on Ethereum, Boyar & Nebula must have up to date state from Ethereum in order to operate. Some of the recent changes to Nebula which also supports this very same goal is providing in the arguments to Nebula an Ethereum endpoint that the Orbs node will use for Ethereum main net access.
In addition, Nebula was refactored to be more concise and easy to contribute to. Linting was added to the project as well to find more errors while writing code, especially when using an Atom-based open source editor (e.g VS Code and friends)
We launched Orbs Community using the Discourse platform. and aim for it to become an open environment for discussion and collaboration about Orbs with the community of all participants in the Orbs Universe - developers, Delegators, Guardians, and Validators. Since Orbs is a decentralized and open source project, any constructive member of the community can become a moderator. Check this blog post for more insights behind the community.
Together with establishing the community, we have revived our orbs-contributor-guide. We value the good community around the project, therefore we have added a Code of Conduct that applies to all Orb network projects. If you are willing to contribute code, please consult with the contribution guide, it should suffice to get you started.
Orbs will have a hackathon on May 22nd-23rd. Its purpose is for the Orbs R&D team to further explore the abilities of Orbs platform, with a view to discovering and sharing new ideas for use-cases and products that can be developed on the Orbs platform. We are excited about getting ideas from the community about specific products you think would be interesting to develop. Join the conversation at: https://community.orbs.network/t/ideas-for-r-d-hackathon/90
The Orbs team is also engaged in theoretical research that we believe the community of developers may find useful in the future development of the Orbs network. The below summarizes some of what we have been thinking about and working on lately.
A key factor in mainstream application' adoption is the ability to provide users with the required privacy. The ability to achieve privacy with the ability to maintain state under consensus and provide the auditability and forkability guarantees is challenging. Multiple cryptographic technologies for privacy solutions are under research, such as zero-knowledge proofs, bulletproofs, multi-party computation and others. We’ve chosen to focus our research initially on zero-knowledge proofs.
Zero-knowledge proofs are a cutting-edge cryptographic tool. They allow an entity to provide proof of some claim, without revealing any other information other than the validity of the claim itself. A popular Blockchain-related use case is the privacy coin Zcash, where zero-knowledge proofs are used in the following way: A payer, rather than uploading a transaction, uploads a “proof” of correct transaction. All verifying nodes of the system may then check that the underlying transaction is valid, without learning who is the payer, what is the amount being paid and to whom. Moreover, they are able to update the transaction pool accordingly, thus fulfilling their role as system maintainers without jeopardizing the privacy of the users.
The Orbs research team continually explores all aspects of zero-knowledge proofs, from theory to implementation. We study the cutting edge protocols for zero-knowledge proofs and examine whether it is possible to bootstrap the unique Orbs network architecture to gain further improvements. Parallely, we research use-cases where zero-knowledge proofs present themselves as a key tool. An example we have recently been focused on is digital identification, a problem with immense implications. In the upcoming Hackathon, we hope to show a proof of concept for a blockchain identification scheme, the core tool of which are zero-knowledge proofs.
ZKProof.org is an open initiative of industry and academia to standardize the security, implementation, and application of zero-knowledge proofs. In early April, a standardization workshop was held at Berkeley. It gathered experts from around the world, both from the industry and academia. The Orbs core team was represented by its lead cryptographer Idan Perl.
The Orbs team is actively researching the topic of non-deterministic execution support in smart-contracts, to expand our platform capabilities. Non-deterministic execution provides two important capabilities. The first is the ability to reach a consensus on data external to the system, which can vary by nature (such as location or a stock price). The second is the ability to identify and remove transactions that result in unintentional non-deterministic execution allowing the block to reach consensus. For example, the non-deterministic state order writes that occurred in the elections contract due to the use of Golang maps.
Most existing blockchains solutions follow the active state machine replication approach, in which clients` operations are ordered and then executed. Here, the backend service distributes the application over multiple servers to enhance the resilience of a client-server application for tolerating arbitrary faults, misbehavior (under certain assumptions, such as honest majority). In this approach, if all servers start from the same state, process and execute the same sequence of operations, then they all maintain a single consistent state.
This design requires the execution of an operation to be deterministic. If the servers process a smart-contract which includes a source of non-determinism, such as randomness, or outside the system data, the result of the operation will differ across servers causing them to diverge, and prevent state progress.
The common approach in blockchain systems for dealing with non-deterministic execution is suppression. Ethereum developed its own execution environment (EVM) along with the Solidity programming language which goes a great length to eradicate all traces of non-determinism (for example allocating variables in memory in known addresses).
This approach hinders adoption - for example, by developers which are used to different General-purpose languages, and prevents robust and interesting features in the application which runs on top.
There are several traditional approaches in distributed systems research, to support non-deterministic execution - rely on a trusted source of randomness - or even Hyperledger fabric blockchain platform design, which altered the operation processing sequence - execution first, then ordering and final validation phase.
We continue to research possible approaches to embedding the support for non-deterministic execution in the Orbs platform.
The Orbs research team is working on completing a paper on the topic of generating randomness.
Apps that require randomness stand in front of a dilemma. If they become transparent, they lose their ability to generate randomness easily. If they remain obscure, users don't have a good reason to trust the app (other than reputation, that can't be based on much). Since the randomness can have great economic implications (by determining the winners of valuable prizes), it could be very profitable to tweak the randomness, predict it, or block its publication. How does an app guarantee (not promise!) the integrity of the randomness generation process it uses?
Our paper introduces a randomness generation service in a game-theoretic environment that an app can use. Intuitively, it can be seen as a “randomness-as-a-service” type solution. Randomness is produced on-demand (rather than as a beacon), instantly (without inherent delay built in), and counters collusion.
A reliable randomness generation process might be useful for the Orbs network one day -- selecting transactions fairly in high load periods, selecting committees fairly (among a large network of validators).
Our very own Shai Yallin spent the first 3 weeks of April on tour with his band Subterranean Masquerade, living on a nightliner and performing music on a daily basis!
···
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.
