Developing on EOS

EOS uses C++ as its smart contracts programming language and also has webasm support. C++ is a low level system language, which while being quite powerful, it also is hard for developers to pickup or transition to from Solidity and other high level programming languages that are commonly used today. On the other hand EOS provides a database and allows developers to update their contracts if they need to. In EOS storage as a resource is RAM where price is determined by the market. In order to deploy your contract, you need to have 10x the contract size available in your account, which can amount to significant costs. Additionally depending on how the contract was designed, it may need developers to actively manage RAM and the other two resources of the EOS protocol, CPU and Network by staking enough EOS tokens just to keep the smart contract responsive. Even though the developer can choose to drop their keys for a contract, in EOS smart contracts are not immutable by default and may or may not be maintenance free and unstoppable. In EOS developers also have the capability to pay for their users resources that lowers the bar for user adoption but drastically increases the cost for developers.

Why use it

Due to its low latency, high throughput, database and the capability for free transactions, EOS is one of the best platforms today to build dApps, where users interact directly with business logic handled by the blockchain.

However its positives, EOS still problematic for user adoption. New accounts can only be created by an existing EOS account that has to cover the cost of RAM needed to store the new account object. In order for an account to interact with a smart contract powered dApp it needs to have enough EOS tokens staked towards CPU and Network and even though there are solutions that reduce these costs, they are not being eliminated any time soon. Users are used to interact hassle and cost free with applications and even though EOS enables dApps to feel as interactive with centralized counterparts it performs worse than ethereum in user onboarding.

Ebakus

Consensus: DPOS

Latency: 1sec

Finality : 85–90sec

Throughput: 23000+ transactions/sec

Write requirements: transaction fees through Proof of Work

Description

Ebakus is the protocol we propose to improve developers experience, while enabling them to reach mass adoption by building usable and accessible dApps. Ebakus uses the DPOS consensus algorithm that allows it to keep low latency while retaining high throughput. Its main novelty is that it doesn’t need a token balance to interact with its blockchain, which in other solutions it was found to be a key blocking point for on boarding new users. Instead in ebakus transaction fees are paid through proof of work; in order for the client to send a transaction they perform low difficulty POW and include it in the transaction object. If the POW difficulty is higher or equal to the one required by the network, the tx gets included in the next block. To mitigate spam Network transaction difficulty adjusts based on network congestion. To allow less powerful clients to interact, they can optionally acquire EBK tokens and stake them so their transaction can get included with lower difficulty. This novelty allows transaction fees to be transparent to the users as the resource used to pay for transaction fees is CPU time that exists in abundance in user’s computers. Additionally ebakus provides developers with an embeddable version of its wallet that can be embedded in the dApp and make the blockchain part completely transparent to the users.