Ethereum will be abandoned in a year.
Abandoning Ethereum in a Year
Having worked with IBM, Oracle, Ericsson and the in Ministry of Internal Affairs of an EU country as a developer, Multiversum founder, Andrea Taini knows the backbreaking and head-racking process involved in the design and development of IT products. And when it comes to developing on the blockchain, the difficulty ratchet up by a factor of 20.
Blockchain developers are faced with a number of challenges when it comes to creating and maintaining an immutable, public ledger system. From resource management to security, performance and scalability, developers not only have a lot of priorities to juggle, but also have to display proficiency and dexterity across a myriad of programming language.
Ethereum was developed as a Turing complete, decentralized computer for programmers to create their own unique crypto asset without having to code and develop a whole new blockchain. But have you ever tried to use Ethereum as Blockchain to insert simple data in it as just mere proof of existence?
Multiversum founder knows the dangers of this firsthand. There’s no doubt about it that Ethereum was developed by a prodigy. However, his inexperience in how real IT projects work, corporate demands, and professional developers requirement has resulted in the scalability difficulties and poor mainstream adoption ratio of the technology. Ethereum was a singular idea that opened the doors to early experiments for decentralized apps. But what lies behind the door? Isn’t the room always bigger than the door?
Developers are always keen to expand on their arsenal of languages, but what they love the most is a product that augment and let them compliment what they already know.
Multiversum offers that all
First of all, we need a standard way of programming with a high level of abstraction to concentrate on business logic instead than managing headache for code that needs to be written again. Modern programming techniques use a component called generically ORM (Objects Relational Mapping) that transform a memory Object (some data in the memory of the pc that define a single entity of the business logic — e.g. A Customer, an Invoice, etc) in an instruction understandable by Databases as Oracle, MySQL, etc.
There are multiple Specifications of ORM, depending on the language used: Java has JPA and JPA has multiple implementations: Hibernate, EclipseLink, etc. This SQL instruction is then sent to drivers (in java are JDBC standard), some other component that communicates with the database itself — a sort of adapter. So, we made a library that — before the ORM — transforms the structure of the memory object in order to make the impossible a possibility — making a single object formed by 2 parts, one the root and one that is the state. Each root can have multiple states in case of update. Relationships goes from State to Root AND version of other object state to which is related. When the library transforms this memory object, it is sent to ORM for being transformed in an SQL string. The ORM then send to the drivers (we made our MTVDBC ones that don’t directly communicate with the DB, but send the SQL instruction and other data to a remote interface). There, the node receive it and only then send it to the proprietary DB drivers.
That is all
All that complexity is managed through transparent channels by our technology! Modern programming techniques, short learning curve, standard procedures mean fast development, fewer bug, short time to market, less headaches and lower risk! At this rate, who will remember Ethereum in a year?