It has been two years since we started working on ebakus and it’s time to start sharing more about it and why we came to build it. Ebakus is a smart contract enabled blockchain solution engineered for performance and accessibility.
So why do we need another blockchain?
It wasn’t a long ago since we decided to work on our own dApp, “a booking platform running on the blockchain”. As with any other project, we started by researching the available solutions to define our development stack. We were quite excited as the promise of decentralized unstoppable programs is a strong one!
Unfortunately, we quickly came to the conclusion that developing a truly decentralized application would not be easy because of the underlying limitations of solutions available at the time :
As we were brainstorming on how to make it happen and as we researched how other teams do it, we thought of several solutions but all of them involved hybrid stacks that were sacrificing decentralization at best. For us, the whole point of getting into the trouble of building a decentralized application was for it to be unstoppable and decentralized, if we were to sacrifice that why not use traditional alternatives in the first place. It made no sense and that sent us to the drawing board with a different question: “There is an opportunity here, how can we make complex and decentralized Applications that remain accessible and unstoppable happen?”
After a lot of funding and hype, the blockchain industry has yet to see a popular smart contract based decentralized application. Ebakus was designed to bring us a step closer to overcoming the hurdles and making this a reality.
For us, the biggest problem is making dApps accessible as it creates a chicken and egg problem for developers trying to make a return on their investment by targeting mass audiences. Since market penetration of the most popular tokens is less than 2% of the population we had to find a solution for the initial need for a token balance problem.
There should be no need for initial token balance or additional software to use a dApp.As mentioned before, blockchains are low throughput networks, which creates the need to have spam countermeasures. Essentially, they need a way to make it uneconomical for malicious users to spam the networks, to avoid these type of attacks (called Sybil attacks), they use fees adding a cost to each transaction. Alternatively, there is the model of staking, where tokens represent network resources and allow token holders upon locking them for a minimum period of time to utilize network resources in a pro-rata basis. Both of these solutions require a wallet and tokens which as we mentioned earlier is the root of the accessibility problem, that leads on bad user experience in decentralized applications (dApps).
Fees in ebakus — HINT: There aren’t any…
To solve this with ebakus, we had to reimagine fees. There should be a resource used to pay for fees that can be spent while remaining transparent to the end user. This resource in ebakus, is CPU. For a transaction to be accepted in the ebakus network, it requires a low difficulty proof of work to be performed. This proof of work only exists to make it uneconomical for attackers to spam the network and should be clear that doesn’t take part in the consensus in the way regular PoW does in bitcoin. It is important to take into account that the proof of work required for a transaction to be accepted is of low difficulty and doesn’t take more than 200ms in a modern mobile phone to be calculated. As the network gets congested, the target difficulty required for a transaction to be included into a block adjusts dynamically to higher targets, requiring more work to be done by clients. To allow accounts with less powerful CPUs interact with the blockchain and accounts that need to interact with transaction-intensive applications to still be usable under periods of congestion, the native token (EBK) can be optionally utilized through staking for a minimum period of 3 days and significantly less proof of work will be required for that account.
Removing the friction: no need for 3rd party software
Making users to download and install third-party software in order to be able to interact with the application logic is something that’s counterintuitive for users. It steepens the learning curve of the application and has them perform additional steps which often translates to further drop-offs during onboarding. Getting users’ attention is hard enough, having them jump through hoops before getting them hooked through providing them with value is problematic.
The wallet, if needed at all in the form we see it today, should be part of the dApp.
A lot of the more successful dApps nowadays have their own wallet implementations integrated into their dApps to remove this friction. For ebakus we have created a turnkey solution that allows devs to achieve just that and even better. Ebakus’ web wallet can also be shared between dApps resulting in users effectively using the same identity and credentials for all the ebakus based dApps they interact with. Moreover ebakus’ wallet solution is much better at removing the friction as it leverages the ebakus fee-less protocol to allow developers onboard users to their dApps in a highly efficient manner that is comparable or even better than their traditional counterparts.
By removing the need for plugins we remove the friction between the any dApp and its target audience. The user is not limited by device and/or platform.
Catering to developers
Being developers ourselves we strongly regard developers the primary persona to optimize ebakus for, as they are the primary value creators of this ecosystem in its early stages and their experience in building and monetising applications directly affects progress and mass adoption. We knew from the start, how important it would be for ebakus to be compatible and allow developers to build on their hard-earned skills so we kept it backwards compatible to Ethereum, the most popular smart contract platform at the time. Ethereum, while popular, is far from perfect though, lacking in performance and without a proper database to handle large datasets efficiently, deeply concerned us while making the initial architectural decisions. We built ebakus to use Delegated Proof of Stake (DPOS), that enables it to reach high throughput (23,000+ tps) with 1sec latency. Moreover, it leverages our proprietary transactional ebakusDB in its core, but also available inside the smart contracts to enable developers to have proper schema defined tables with indexes.
If you are a developer working on a dApp and like us find these limitations are holding you back, stop reading and go check out Ebakus. On our website you will find our boilerplate and relevant documentation to get you started and you are always within reach on our discord and telegram channels.