Subsquid was born within the Substrate ecosystem, as such it natively supports all Substrate-based blockchains. But cross-chain and cross-technology communication and compatibility has become more and more important as of late. Over time, projects have started to look into onboarding developers with Solidity experience. For this reason, they have been working on ways to make the transition to Substrate, and the Polkadot ecosystem in general, easier for Web3 builders.
The ability to process both Substrate-native entities and EVM contracts with one single tool opens the door to a world of technical possibilities for these developers: it empowers cross-chain communication and serves natively multichain ecosystems that are already thriving and growing.
It is in this context that we at Subsquid have made the strategic decision to develop and release a new Processor that natively supports EVM logs. We have already explored this great new tech feature in detail in our recent partnership announcement with Astar, but in this article we’ll give an overview of what it means for Web3 builders and the Subsquid ecosystem as a whole.
Uncovering new features 🤯
I had the chance to play around with this new feature recently in order to familiarise myself with it, and I think we really stayed true to our purpose. This tool really does make it easier to onboard developers to the future of Web3!
This EVM-compatible version is an extension of the Processor our dev users should already be familiar with. It simply exposes a new method: addEvmLogHandler, to “hook” a custom function to process an EVM log, and a few helper interfaces (e.g.: EvmLogHandlerContext) to pass data around.
Following the same principles as always, the block-processing loop alerts the Processor subscribed to the specified event, under the specified conditions (the addEvmLogHandler function optionally accepts a EvmLogHandlerOptions argument to further reduce the scope and filter down triggering events) and the custom business logic is run. There are, however, a few additional steps that differ from the process of developing a Squid for a blockchain with only Substrate entities.
Solidity developers certainly know about the contract ABI. For everybody else, ABI stands for “Application Binary Interface,” and it’s essentially a standard to define the data structure, including types of contracts in the Ethereum ecosystem.
Subsquid has developed elegant and very useful tools to speed up development, and make it less painful, by automating the generation of type-safe wrappers around Substrate Events and Extrinsics.
This is one of our major features, and something that we are very proud of. We really believe that this separates us from other similar frameworks. Thanks to this feature, developers can sleep soundly at night, safe in the knowledge that their application is robust to changes in the blockchain Runtime, and that in case of updates a simple regeneration of the interfaces will do the trick.
It is worth mentioning that a similar feature has not yet been implemented for EVM contracts, so developers will have to manually source the ABI (in its JSON form) and build EVM log decode functions, for the time being. However, this feature is being built right and plans for its release will be announced soon.
Here’s an example of how to manually source the ABI in this manner:
This process requires a bit of prior knowledge, but the information can be found in the ABI itself. As can be seen in this image, it is indicated that the signature for the Transfer event is composed of two addresses and one integer:
The rest of the developer’s work, as already mentioned, is about implementing a custom business logic to map defined database entities with EVM log data.
The Open Ocean Council Program is in full swing, and the first two Community Quests have been handed out, one is even under review as I write!
Thanks to docker-compose files our Archives can be deployed in just a few seconds by any infrastructure provider. However, we wanted to make this process even easier, so for our first team Abyss quest we engaged our community to produce Helm configuration files to deploy an Archive in a Kubernetes cluster. Our community members hastily responded with some great solutions which we are currently testing.
The second quest has to do with monitoring: Subsquid Archives expose Prometheus metrics to report on key performance and health statistics. We tasked the community with developing a Grafana dashboard to visualise such metrics. After all, we all know that an image is worth a thousand words!
Stay tuned to see the results of these quests and to hear about new tasks. Is anyone interested in developing a Squid API of their own? 👀
Significantly, we have also just created a Community repository. In the future, submissions that don’t already link to an existing project will need to go into the new repository. This will serve as the base of operation for our Community.
Hackathons are awesome. They are a great way to directly engage with our community; have meaningful conversations; explain our product, our goals, and our path to get there; answer questions; and consolidate all of this through practical applications of our technology.
That’s why I am personally putting a lot of effort into preparing our next event, where the goal will be (without giving away too much) to build a Squid API🦑.
Putting such events together certainly takes a lot of effort — every detail needs to be ironed out, and we need to ensure that we anticipate as many possible questions and roadblocks as we possibly can. It’s like implementing the solution to the problem before asking our community members to solve it!
We anticipate being able to collect lots of feedback from this experience and believe that the level of engagement that results from it will bring a positive return on the time and energy we devote to it.
I really hope to see many of you at the next Devconnect in Amsterdam in April. I can’t wait to discuss Subsquid and your great ideas for its future!
Subsquid’s Official Channels
Email list: https://eepurl.com/hBOqLT