Twitter Space conversation full text transcript
As the compatibility layer on the EOS network, Trust EVM features super high performance and familiar Ethereum tooling for developers. Thanks to the high compatibility, Ethereum native applications can be ported to Trust EVM seamlessly, while enjoying the low transaction costs for users. So many developers are paying close attention to the implementation of Trust EVM testnet. Now, the preview version is available and the Jungle testnet version is coming soon.
On June 16th, we held a fascinating and insightful conversation with developers and the community on Twitter Space. We invited two speakers to join. Matias Romeo, the EVM+ technical lead and Esteban Saá B, the leader of TrustSwap built on Trust EVM.
The topic for the Twitter Space is: How will Trust achieve the fastest EVM?
On Space, Matias introduced the current progress of Trust EVM testnet, what‘s our next step, and how trust will achieve the fastest EVM. Esteban shared some information about TrustSwap, and why built it on Trust EVM. Also he got the Grant from EOS Network Foundation, he shared some experiences about the Grant.
Keynotes by Matias, the EVM+ technical leader
Transcript:
The idea of this Space is talking about:
- How the development of Trust EVM is going, the current testnet implementation.
- The next one that we are soon to release.
- Some other details about how we are trying to have the fastest EVM on EOS.
Basically in this session I will talk about the existing architecture of the testnet, some limitations that we found and how we will address them on the next release. Talk about a little bit of Silkworm.
The Trust EVM development
There are some projects that we are integrating into Trust EVM and the new protocol features that are coming in next month’s release. As you may already know. At the beginning of the project, we had two options about how to implement this compatibility layer on EOS, and how to implement Trust EVM. So one option was to implement natively on the EOS, and the other one was to have a smart contract, a regular contract on EOS. We knew that native was more performant, even if the runtime of EOS is pretty fast, native is still faster. But it’s less flexible. When a new EVM version comes out, it will force all the node operators to update the software. So we decided to have a smart contract.
We know that the EOS runtime has a pretty good performance, and it also gives us more flexibility, as you’ve already known. EOS contracts can be updated with newer versions. So this is the path we take. We developed a C++ smart contract, basically, we integrated EVM One. EVM One is the fastest Ethereum Virtual Machine implementation in C++. And the codebase of EVM One is optimized to provide faster and efficient execution of EVM smart contracts. But supporting EVM, the runtime is not only having an EVM compatibility layer. And developers need a way to access the current state and also query for history. So this is where the Web3 JSON-RPC comes in.
The existing architecture of the testnet
Every Ethereum client implements JSON-RPC specification. There is a uniform set of methods that applications can rely on to query for state information to send transactions etc. Due to the state of EVM, smart contracts persisted inside the EOS state. One possible solution that we thought of was to map every JSON-RPC request to a query of the EOS state of the EVM contract. But it’s not that simply because there are some specific calls on the JSON-RPC specifications that need access to historical state. For instance, you can query like, I want to know what the storage of this contract at this position was, not at the head block at the current state, but in the past. Also you can query a specific balance of an account also historically, or you can execute a transaction and see the traces. But you can also execute that transaction at an arbitrary block height. So what we decided for this release of the testnet was to use a regular Ethereum client to serve those JSON-RPC requests. So basically what we are doing right now is we have the EVM runtime contract on the chain, and after the transactions are executed on the chain we extract them from the EOS blockchain and Jungle blockchain. In this case, once they have been applied, we feed them to an Ethereum client using the Peer-To-Peer wire protocol. So basically we have a gas node, one of the regular Ethereum clients that is receiving all the transactions applied into the EVM contract on the EOS blockchain and Jungle blockchain.
Some limitations that we found
This works pretty good, but we have some limitations with that descent.To simplify the architecture that we have right now on Trust EVM which is running on Jungle for testing, we have the smart contract, which is the C++ contract using EVM One. We have a separate service called the translator service that extracts transactions from the block chain and feeds them to a gas node. And this gas node is the one that exposes the JSON-RPC interfacing to the world. It is the one that you are using when connecting with Metamask. You’re pointing to one of those Ethereum nodes, and then we have a wrapper that basically handles the incoming transactions and wraps transactions into an EOSIO TX transaction then pushes it to the runtime contract. Even though the architecture works fine, it has many moving parts.
We will address them on the next release
We started thinking about having a simpler and more integrated setup from the perspective of a novel operator, like a more integrated setup. This is where the previous design of the EOSIO comes really handy. One of the cool features of the EOS node program is that it was built using Appbase. Appbase is a library that provides a basic frame for building applications from a set of plug-ins. Appbase manages the plug-in life cycle and ensures that all plug-ins are configured initially and shut down in the propagator. So you can construct an application that comes from a set of plug-ins. We can extend the functionality of the EOS node by writing a custom plug-in that a node operator later can choose to enable or not at the moment of running his node. This is part number one that we can extend the EOS node functionality by writing a custom C++ plug-in. In fact, there are many plug-ins today, each of them addressing a specific proposal on the EOS node.
Silkworm
On the other hand, there is Silkworm. Silkworm, as many of you know, is a C++ implementation of the Ethereum protocol written from scratch that is based on the Erigone architecture. They are aiming to be the fastest Ethereum client while maintaining a high quality of the readability of its source code. So it’s a pretty awesome project having a lot of attention right now. So since the EOS node can be extended using plug-ins, we have an Ethereum C++ client implementation that is heavily focused on efficiency. We decided to create a plug-in for nodes using Silkworm that will be responsible for serving the JSON-RPC requests to the EVM. When this plug-in is ready, if you want to run your own Trust EVM node, you will just need to run the official EOS node with this new plug-in enabled. You will be able to serve JSON-RPC requests, or you can use it for development purposes, or showing a testnet, or showing mainnet, or any other type of configuration that uses it. This simplifies a lot from the previous architecture, since all the necessary functionality will be bundled together in the same EOS node. And if you think about exchanges that want to list some token on top of Trust EVM. We also think about the operation problems that having many moving parts for a specific deployment can have for the developers team. So having just one node with a known configuration, it’s a better architecture from the one that we had. So this is where we are going, at last, I want to talk about the Mandel new protocol features.
We’re trying to achieve the fastest EVM on EOS
There are new protocol features in Mandel. For those of you who don’t know, Mandel is the upcoming version of the official EOSIO that will help us with the execution of the EVM runtime. There are special kinds of contracts that are bundled within the EVM at fixed addresses, offering a set of advanced functionality that are quite expensive in terms of computation time. Most of this functionality was already supported on EOS like Hashes and key recovery algorithms. The EVM runtime contract is just using them, linking to them and using these specialized functions. But some others were not, so we have to implement them on a web assembly level instead of having a native implementation of those precompiled content. But the EOSIO protocol has a pretty nice feature which can be extended by adding new protocol features so that block producers can activate at their will.
We have submitted two new protocol features to the official EOS node that we have this new native function. We will add new functions to the EOSIO protocol that will help to speed up the calls to the Ethereum pre-compiled contracts which are bundled in the EVM. The Mandel release 3.1 RC1 has all these new features integrated and it started to be deployed on Jungle for testnet. So as soon as BP’s update to the newer version and these protocol features are activated, the EVM runtime will start using them.
I think that we will have a pretty nice combination of flexibility in terms of being able to keep up with the updates on the EVM since we have the EVM implemented at a smart contract level. But the things are expensive in computation time, the Ethereum pre-compiled contracts will be easier intrinsic and supported in these new protocol features. For the RPC part, having this new Silkworm plug-in integrated into the mainnet, EOS node will make life pretty much easier for node operators that want to run a Trust EVM node. So this is the update on my side. We are pretty excited to be releasing this new testnet as soon as we can and you can ask whatever question you may have, thank you.
Keynotes by Esteban, the TrustSwap leader
Transcript:
I think the best way for me to tell you what TrustSwap is, is to tell you a little bit about how we got started and why we decided to build the TrustSwap on the Trust EVM.
The story of Esteban with Trust EVM
I was checking the news not long ago and I got across this news about a new EVM and got my attention. I was very curious because there was some interesting information on how we work, how we were connected, and some technical decisions around it that got my attention. So then I said, okay, I’m gonna to test this and see what it is about. So then I went and configured it, and a few minutes later I had some coins from the faucet and I was working really well. And then I said, okay, I’ll give a try deploying some Solidity contracts, you know, so I tried. I think the first contract I tried and it was working really fast, very easy. And it got my attention how fast it was because I had worked before in other EVM Ethereum and Binance Smart Chain and so. So it just got my attention how fast this EVM was. What is this? How would you be able to make it work so fast? So that was really interesting. And so I said, okay, I’ll do another thing. I’ll try this order contracts and start testing a few contracts, and everything was just working and it was working well. There were no problems with compatibility. Everything was just working. So I started going deeper into EOS and joined the community and started sharing with the community all these things that I was doing. I’m like, “hey you guys, you know, I deployed this contract and it looks very interesting.” And the community was very responsible, like “yes, we’re doing this, we’re doing that. Why don’t you try this? Why don’t you try that?” So I started doing that. You know, I started testing more contracts and getting feedback from the community. And then we started this circle of information, and I didn’t start seeing this community that was well organized to have all these projects and all these ideas and all these things going. That got my attention. So I said, wow, this is a really great community dowelling on so they have this great community and they have this great platform.
Awesome experience of deployment on Trust EVM
I should try to go beyond the test and try something more challenging. So the next idea was, okay, I’m gonna deploy the most basic infrastructure contracts. And I tested deploying. I think it was multiple contracts and I tried deploying rapid contracts and everything just worked. So I was going to deploy something even more challenging. So I then took the code from UniSwap and put it together very easily. It was working like magic. It was working, but it was working fast.
When we did a swap on Trust EVM, it was just like lightning. So the user experience is so good that it’s gonna get a lot of attention from users. So I said I have to build something. I have to create something in and become part of this community. And the community was very welcoming. So I said: “Okay, I have deployed these and people started testing and trying it and giving me feedback.”
Esteban team got EOS Foundation Network Grant Framework
The next step was to build a company around this infrastructure. I want to build a company around this community. So then I was looking for “okay, but how do we fund it?” We need some resources. We need some guidelines. We need a way to make this happen. And so we were directed to the ENF (EOS Network Foundation) Grant Framework and then we said “okay, we’re gonna apply for the ENF Grant Framework.” The process was extremely easy. It’s so well organized. Basically, there’s this GitHub repository that you could clone. Inside the clone, the code or the text, there’s a basic layout of information. You fill and create a pull request with it, and that’s it. It’s very easy. It’s very simple. We sent an outline of the project and it was reviewed by the ENF. Then we got a little feedback, and we were funded later. We now have the funds and we have the backing and the support to create something extremely good on top of Trust EVM. So that’s what we’re doing and that was the start of TrustSwap.
TrustSwap got started building on Trust EVM
I want to extend a little bit about how TrustSwap started. It’s a swapping service, but we want to take it further. We want to solve an important thing in the ecosystem, and that’s being able to show you what is cool inside the ecosystem.
The new projects and their tokens are going up and getting attention from the community. And things are probably cooling down. And they should have so much attention. So that’s what we’re trying to do. We’re trying to create this service on top of Trust EVM with an amazing user experience. Let you swap tokens quickly for very low fees, and give you this information on ‘what’s cool, what’s the next big project? What is the next token that you might want to get before the price goes up? Or what project is probably cooling down a little bit, and maybe it’s time to sell.’ So Trust EVM allows us to create these things. And in this compatibility layer, it’s extremely important to have this compatibility layer because you’re not closer to the other networks. You’re able to reach further. You’re able to bring value in and you’re able to export your ideas, your product. So someone creates a project which contains a token inside the user ecosystem. It’s probably a really great idea that the project becomes available further and gets access to more and more liquidity and more people. So that’s why this compatibility layer is so important that we build on top of it.
That’s a little bit of TrustSwap and what we do in the idea of not just staying with the basic swap service, but also adding this idea of being unable to discover what is cool, what’s hot, what’s cooling down, being able to make your choice to have a broad list of options of tokens and being able to select from those options.That’s what we have now. But we see further and we want to take this beyond what it has already been done. These are not new ideas. We’re empowering these ideas because we have this solid foundation of really fast, scalable, compatible EVM that we can build on top of it. There are a large number of contracts and ideas that can be easily ported into Trust EVM. The compatibility is great. It means that you can just take other ideas and bring them and improve them. Because you have this quick finality, quick blogs, and that just improves their user experience so much.
Benefited by the fastest EVM, soulbound token goes further
At the beginning we had these 10 minutes blocks on Bitcoin, but when the team came and had these 15 second blocks, it fell so fast. But nowadays paying hundreds of dollars on Ethereum for a transaction and having to wait 15 seconds, 20 seconds, it doesn’t feel so good. So we have this new platform where we can have really fast blocks. You just click and swap is done and you pay very small fees. And then we want to take it further. So this is really cool.
I want to share with everyone some ideas that go beyond what is available today, and it goes into what this platform allows us to work. So we have coins. That’s how this crypto revolution started. We have coins like Bitcoin and EOS, we have tokens like USDT and a good platform of tokens. New world ideas came later like NFTs, not-fungile-token, in which each token is different from the next one. So I want to tell you about what comes next. What is gonna be the next big thing in crypto? Vitalik sees the future, and he talks about this new idea called soulbound tokens.
Brief introduction to soulbound token
The soulbound tokens are something that I already existed in EOS before. So let’s explore a little bit. What are soulbound tokens? The crazy thing is, a soulbound token is something that already existed in EOS before. Soulbound token at its core, is about identity. Soulbound tokens are these tokens that are given to you, and once you receive them, you can not send them away. There’s a part of your private key. You receive this and you cannot send it away. So how is this useful? I said that the soulbound token was about identity. So if you receive a soulbound token from a registration company or an identity company, the company is certifying that you say that you do. You are who says you are.You’re not who says you are. So you solve this problem of social networks having lots of spambots. Because now with your soulbound token and your certification, there’s no way that there’s a filter bots. So talking about this idea makes it possible for identities to be real, to stop bots and spam accounts. But it doesn’t end identification or identity for people because we are beyond identities. For example, not only people can have identities, but anything else can have an identity.
A car, for instance. A car may have an identity. You might receive your special soulbound token that allows it to work in certain parking spaces. That’s a soulbound token, and it’s applied to that car or to the person that drives that car. Maybe that person got a disability. So the certification company then creates the soulbound token and keeps it to this person who is now able to drive his car into this special place in the city. A company might be doing great on reducing its carbon footprint. A company or service might provide a soulbound token. For example, they now need to pay lower taxes. So we can apply this idea of soulbound token to lots of things, not just people but things. Cars, companies, cities, parks. Anything can receive a soulbound token. And so you have this immense domain of things receiving digital identities and properties. And then we can start connecting these ideas. How are they related? For example, you go to a restaurant and you are provided a review. That review is a soulbound token, because it came from a person who got a soulbound token which verifies a real person’s identity. That review is true. There’s no one that paid to get a review, but that review comes from a real person, not from hundreds of bots, not from 100 accounts or whatever. But from a real person. So this is just a very top and the very small part of what soulbound tokens are.
It just happens that Trust EVM is the perfect infrastructure at EOS, and it is the perfect infrastructure to wield all these new ideas. So we don’t want to stop what has been done already. We want to innovate, we want to create, we can do that. Thank you to the help of the EOS community and infrastructure that they are creating. So we can bring these ideas to life and hopefully use them to have a powerful impact and improve things in this world. Thank you.
Thanks, to our speakers and listeners for attending this Twitter Space. Moreover, we had a closer contact with developers in the AMA session. The splendid content of the AMA session will be posted next week. To get more information about Trust EVM, you are welcome to join our community.
Website of Trust: https://trust.one/
Twitter of Trust: https://twitter.com/trustevm
Discord of Trust: https://discord.com/invite/v6ewc37FaK
Telegram of Trust: https://t.me/TrustEVMDev
