Year to date
The team have been working hard on realizing the vision set out in the original Whitepaper and on updating the protocol to take into consideration what we’ve learned since starting our journey to deliver a fully decentralized protocol on Ethereum.
The development team working on the Aventus Protocol structure the delivery of the protocol and associated work into epics, each epic being reasonably large in terms of effort and with a common objective or theme. In broad terms each epic will have a driver, these being:
- Theory: The blockchain landscape is constantly evolving and it is crucial that all works are designed, developed and delivered in the context of current thinking.
- Adoption: All solutions must be capable of being reworked or redesigned to allow for greater adoption.
- Decentralization: All solutions must be aligned with the ultimate objective of delivering a decentralized locally deployable part-open-source software project.
As well as a driver an epic is assigned a type which is used to indicate the nature of the bulk of the work involved in each Epic. The types are:
- Research and Development
- Development and Analysis
- Both the above
- Aventus Classic Development & Analysis
- Aventus Protocol (Proof of Authority network) Tier 1
- Modularize Aventus ‘Crypto’ Wallet Adoption Development & Analysis
- Aventus Protocol (Proof of Authority network) tier 2 Development & Analysis
- Interchain Architecture Analysis (1/2) Decentralization
One of the team’s main goals, and the key focus of Q1 and Q2, has been to build out Aventus Classic, which satisfies the original whitepaper.
Aventus Protocol (PoA Network) Tier 1
The beta version of the protocol has been in the market on the main Ethereum network for a year. Our expectation was that some of the challenges we faced with scale and privacy would be solved by Ethereum. This did not happen within the timescale we’ve been working to and we therefore needed to solve the challenges ourselves to satisfy the commercial requirements for a solution capable of operating at scale with the necessary levels of security. Our approach was to design a tier 2 solution, operated in a proof-of-authority type of network, where the operator can be challenged on the main network and all state changes are checked and can be challenged automatically on the main Ethereum network, in what we call the Aventus Protocol (PoA Network) tier 1.
To support all the changes within the updated white paper it will be necessary to build test implementations of the key touch points with the protocol, for example how does the Protocol validate a proof. It will also be necessary to significantly rewrite all elements of the ecosystem which interact with any of the new protocol behaviors.
Modularize Aventus ‘Crypto’ Wallet
It is important to be able to demonstrate the advantages of integrating with the Protocol and this can be achieved through the development of reference applications, mobile applications that combine the difficulty of DApp building with the broader challenge of maintaining applications that have to be capable of running on numerous and rapidly evolving mobile devices.
One of the reference applications built to show how consumers can redeem and transfer their tickets and other digital assets is the Aventus ‘Crypto’ Wallet. Creating a more modular version of this facilitates wider adoption of the protocol, combining features already built into modules so anyone wishing to adopt the Protocol can pick and choose which protocol functionality they want to include in their own mobile applications.
The baseline wallet contains core asset loading and display functionality, and this can be extended to provide a turn-key solution.n.Modularization makes it easier both for building a new app and for incorporating support for the Protocol into existing apps.
The SDKs for the modular Aventus ‘Crypto’ wallet will eventually be provided under an open-source license.
Aventus Protocol (Proof of Authority network) Tier 2
Aventus includes a number of tier 2 components the three most important of which are:
- Honest — reads from the protocol
- Patient — queues transactions to the protocol
- Modest — provides support for large volumes of data
Honest, Patient and Modest are collectively referred to as the Virtues. Connecting directly to the Aventus Protocol on Ethereum is not viable for many enterprise clients as this presents a number of challenges for most existing ticketing architectures, notably around scale and privacy, as well as requiring specific developer skills. This is why these specific components of the tier 2 proof of authority network have been developed.
The tier 2 components (Virtues) handle the complexity of working with Blockchain technology and address scale and security and our hope is that this will result in many more enterprises being willing to adopt and use the Protocol. A Sandbox environment for 3rd party developers allows for experimentation and testing of the technology.
Interchain and Layer 2 Consensus Architecture Analysis
The team working on the Protocol have been exploring the properties of other blockchain solutions with the goal of having the Protocol support more than one blockchain and are looking at use cases similar to ticketing as well as using an alternative chain for specific parts of the ecosystem, such as payment. The work includes a deep dive and low level prototype(s). This work was undertaken within two phases, an initial research phase that involved examining a wide range of relevant technology at a fairly high level to identify candidate projects to help with the broader ecosystem, and a second phase focused on prototyping and hands on usage with those technologies as part of a final appraisal before potential inclusion in the broader protocol.
- Aventus Protocol Proof of Authority network Ethereum-based protocol v1
- Decentralized Tier 2 Research
- Aventus Classic
- ZK-Snarks Implementation
- Business Rules Engine
- Developer Engagement
- Updated Whitepaper and Light Paper
The major protocol changes in this Quad reflected the use of Ethereum to underwrite the transaction scaling properties of the Tier 2 solution. These changes required substantial analysis and experimentation.
Aventus Protocol Proof of Authority network Ethereum-based protocol v1
The Aventus Protocol Proof of Authority network tier 2 solution will be elaborated on in the upcoming whitepaper.
Decentralized Tier 2 Research
With the release of Protocol v1 it was time to realize the vision of a decentralized version of the Protocol, as shared within the original Whitepaper from 2017.
The objective was to research and build a Tier 2 blockchain on Ethereum where Aventus network participants will be able to run a node, much like Bitcoin and Ethereum participants can. The nodes will form a peer-to-peer network, with any Aventus transaction propagation across the network being processed by one of the nodes into a block, and all nodes coming to consensus on blocks to add to the chain. Tendermint technology was explored and a proof of concept built and the Protocol development team are now positioned to have the use of Tendermint to build out the full decentralized V1 as an option.
The team have been further developing Aventus.js, adding and updating documentation, and working on new additions to improve scale based on learnings in solidity. A formal release of Aventus Classic is planned and will be referenced in the upcoming whitepaper.
Following in-depth research we took a decision to use Zero Knowledge Proofs to allow users of the Aventus network to prove they have a barcode for a ticket on chain (therefore proving it is their ticket) without publicly exposing the barcode itself. We are among the blockchain market leaders in the field of ZK-Snarks making valuable contributions to various blockchain projects.
We are building libraries for iOS and Android mobile platforms which support proof generation and a library for server-side verification of our Snark implementation. Considerable effort has been spent on the optimization of the code, some of which has needed to be created from scratch on account of the newness of the technology, as the computationally intensive algorithms associated with Zero Knowledge Proofs have to be capable of running on resource constricted smartphones if there is to be mass adoption.
Business Rules Engine
Rather than prescribing which rules an event owner can choose from governing their ticket inventory we have been exploring a more general purpose rules engine which can be configured by the ticket seller, enforced by the Aventus network Proof of Authority operator and enforced or challenged if needed on the main Ethereum network.
A developer engagement project has been established with the goal of making Aventus tier 2 more approachable and accessible for interested 3rd party developers. Treating 3rd party developers as users of our documentation, this initiative is a commitment to continuing to refine and improve the developer experience associated with using the Aventus protocol and includes:
- making it easier to sign up to use Sandbox environments
- creating ‘Getting Started’ guides and explainer videos
- engaging with developer users to refine and evolve the developer experience and supporting materials over time
Starting this project now and committing to this approach over time is a crucial part of the longer term plan to move the Aventus Protocol to the open source community.
Updated Whitepaper and Light Paper
Through engagement with the ticketing industry we developed a greater understanding of the nature of ticketing and the challenges within the industry. As we continued to share our vision of a Protocol composed of Ethereum smart contracts that would allow for the creation and validation of events, the issuance and sale of tickets in primary and secondary ticket markets, and the distribution of ticket sale revenue and market/event fees between the event organisers, ticket promoters, market matchers, attendees, etc. we realised that in viewing tickets as digital assets and in building a tier 2 based Aventus Proof of Authority network we were in fact building a solution that could easily lend itself not just to ticketing but to digital asset management in general. We therefore started having conversations with other sectors that use digital assets requiring business rules and permission management.
These conversations are sufficiently interesting for us to have made a decision to update the whitepaper. We will maintain the original elements described within the original whitepaper which will now be referred to as Aventus Classic, while illustrating some key findings that hindered its adoption. We will propose tweaks to the Aventus ecosystem to position it to have the best chance at becoming a standard for the ticketing industry, but also and importantly position the Protocol to be applicable more generally to other types of digital assets. In taking this approach we recognize the importance of having any potential other use cases for the Protocol thoroughly reviewed to ensure regulatory compliance of AVT.
Various authorities have become much more aware of tokens and whilst the frameworks they are creating are continually evolving, there is certainly more information available than when we set out on this mission.
In Q3 we are focusing on the following epics:
- Aventus Protocol Proof of Authority Network v1 release
- ZK-SNARKs (Continued)
- Advanced Asset Rules Engine
- Tier 2 P2P (Part 1/x)
- Third Party Developer Engagement
- Architecture Scaling and Resilience
- Ecosystem Toolkit
- AVT Usage & Full Whitepaper
More details will be posted in various posts over the next few months and within our Q3 roundup
Would you like to get in touch with us?
Email: email@example.com | Website: www.aventus.io
We have also created a group for open-source developers/ ticketing developers and ticketing professionals and invite you to join it here — Ticketing on Blockchain.