MainNet In Sight

Introducing OAM: increasing transaction throughput while maintaining efficiency and security


Hello imbrex community!

Last week, we announced the imbrex Ambassador Program to seek out community members who are passionate about imbrex, and would like to participate in the project’s expansion by educating and onboarding early adopters. There has been an overwhelmingly positive response and we are humbled by it. Applicants will be contacted within the next two weeks. Thanks to all who applied!

The team has spent the last four weeks immersed in Alpha testing. The majority of bugs presented themselves in the front end and Imbrexer. We also created several new extraction calls for the front end to get data from the contracts via the Imbrexer.

This brings us close to MainNet-ready, but before migrating, we’ve decided to upgrade the Subscription Model to better prepare for future scaling. In our initial deployment strategy, we envisioned implementation of two successive designs for handling transaction throughput across the first eighteen months. Model #1 would handle processing for the first wave of imbrex subscribers during months 1-6 and Model #2 would be deployed in month seven to cover the subsequent six months. However, we believe we underestimated Subscription demand and have decided to deploy Model #2 as our MainNet release. Listening to user feedback and providing a top tier user experience are two imbrex’s core principles and the team does not want to cut corners in exchange for a faster release schedule. We started building Model #2 and plan to have it in testable condition in a few weeks. Once thoroughly tested and stabilized, we’ll migrate to MainNet. In the ensuing post, we will explain the technicals behind Model #2.

First, let’s review the difference between imbrex’s Non-Subscriber and Subscriber Models

On imbrex, non-subscribers pay their own Ethereum transaction fees. These fees are paid in the form of ETH and are referred to as “gas”. Paying gas powers the network. As a non-subscriber, the user adds their listing to imbrex through the user interface. This sends the transaction to the Ethereum network and makes a forward function call to the listorData contract. The ADD_LISTING function checks a set of required conditions. MetaMask is then triggered and the user pays the Ethereum transaction fee from their MetaMask account. The listing is then sent through the imbrexer and injected into the Web 3 environment.

As a subscriber, the user also starts by adding a listing through imbrex’s user interface. Next, imbrex creates a transaction with one of imbrex’s owner addresses. A transaction is then made to the forward function of that user’s pseudo contract which then forwards the call to imbrex’s listorData contract. The transaction fee (that’s the gas paid for in ETH) is pulled from one of the owner addresses and the fee is paid. The subscriber has the benefit of never having to leave imbrex’s native application in order to purchase ETH, send it to imbrex, then fund their own transaction fees.

User pseudo contracts act as a prima facie for the user and imbrex to have joint control over the contract. It is the key that gives imbrex the ability to sign transactions, thus providing a forwarding mechanism to pay the transaction fees on the user’s behalf. It’s important to note, ETH is never stored in the user’s pseudo contract.

The challenges with scaling this model….

Scaling problems with Model #1

Imbrex controls what we call Owner Addresses for processing Subscriber transactions. Imbrex uses our Owner Addresses in conjunction with a Subscriber’s pseudo contract to process gas fees. The challenge is that decentralized applications running on Ethereum can only process one transaction at a time through a given address. This works while we have a small number of users with limited transaction throughput, criteria that satisfies our initial projections. However, as traffic increases, a transaction backlog accumulates behind each Owner Address. This can lead to transactions at the front of the queue (for a given Owner Address) being overtaken by transactions at the back of the queue. To overcome this challenge in a temporary setting, we could increase the number of Owner Addresses, but it would be at the expense of efficiency and security: two values we are not willing to capitulate on. That brings us to OAM, Owner Address Management.

Solution: Start with Model #2

In Model #2, we introduce OAM our system for Owner Address Management. The Subscription model includes an Owner Contract; a contract that facilitates transactions between imbrex’s backend pool, user pseudo contracts, listorData contract and imbrexer. On the backend, imbrex has x owner addresses that are distributed into groups. The Owner Contract starts by communicating with each subscriber’s pseudo contract and assigning it to one of the owner groups. As subscribers engage in transactions on imbrex, they are forwarded to their respective owner group. The user’s transaction is assigned to the first address in their assigned group that is not currently processing a transaction. If no address is free, the transaction will continue to loop within the assigned group until an address becomes available. Imbrex can now process many more transactions than we could in Model #1. We can scale this model more effectively by incrementally adding new groups to fulfill increased demand. OAM comes with a ceiling in the number of new owner addresses we can securely deploy into each group. However, the team has already drafted a solution (Model 3), that will be presented in the fall.

How long will this take to build, test and release?

The team has finished writing the contracts and the backend is being assembled as you read. We expect it will take approximately three weeks from today to finish coding the upgrades to the Subscription Model. During this time we will invite community testers into the Alpha to ferret out existing bugs before MainNet release. Ryan is working on a bounty program that will reward testers in IMBREX tokens in exchange for valuable feedback and bug reporting. Please stay tuned for the announcement.

Conclusion

We thought about going to MainNet with the Non-Subscriber model and deploying the Subscriber model following completion of Model 2. As a team, we decided the Non-Subscriber and Subscriber Models should be released concurrently. We will continue to update the community on progress made in the coming weeks and look forward to testing then deploying this feature in the live environment.