We talk Ethereum with Andrej Bencic & Bogdan Habic from Tenderly

It’s always impressive to meet the talented people building in the blockchain ecosystem. This week I got to chat with two of the co-founders at Tenderly, Andrej (CTO) and Bogdan (Distributed Systems Engineer) following their win at the ETHBerlin Zwei hackathon last week for their entry, sol.tty. It was a great chat, and an awesome project, hope that you enjoy learning about it as much as I did. 

Colin Platt (CP): Hey guys, hope that you had a good trip back from Berlin, and were able to rest-up after the week. Thanks for taking the time to speak with me.

Andrej Bencic (AB): Hi, good to talk to you. Yes it was an intense trip, it was a very packed agenda and we were super busy the whole time. It was a really good and was good to meet people you know from the internet in real life.

Bogdan Habic (BH): Yeah, we met a lot of people and I don’t think that I’ve ever shaken so many hands. A great event.

CP: So tell me a bit about yourselves. How did you get into this space?

AB: We’ve worked together for about six years now. We met in high school in Serbia and have been working together ever since. We started doing software development together back then and done several hackathons together.

BH: You could say that the hackathons have become a benchmark of our friendship. If we don’t win our friendship is over.

AB: We’ve started two companies together, while working together at four altogether, doing software engineering.

BH: Guess that because we’ve been working together, sometimes it’s hard to add in the intro. I’m a distributed systems engineer and have always enjoyed working with scaling issues. Previously I’ve been in “traditional” software engineering, with a focus on cloud. I became a fan of cloud because of the ability to leverage it to build huge systems with a small team and make a large impact. The Ethereum ecosystem is interesting because it is very young, and are still working to bring scaling. I became interested with the challenge of how to bring better visibility into the blockchain. Before launching Tenderly we worked together as part of a startup called ManageWP, a WordPress management platform, which got acquired by GoDaddy in 2016.

AB: About a year ago, we entered an Ethereum hackathon. We wanted to build a trustless, public tender project for governments to get bids for projects. That’s where the name “Tenderly” came from. We continued to build the project out after the hackathon, and talked to the people at GovTech Pioneers in Vienna for potential projects, but then discovered two things. First it was hard to talk to governments, and secondly there was a lack of tooling in Ethereum. We really enjoyed building dev tooling more than talking to government procurement teams. We liked the name though, so kept that and open sourced our internal dev tooling.

CP: So tell me about Tenderly.

BH: Tenderly is a smart contract monitoring platform focused on bringing visibility to the development and deployed phases of Ethereum smart contracts. We bring dev tools to help successfully manage deployed smart contracts, as well as help developers deploy faster. Debugging smart contracts is time intensive so we built human readable stack traces for solidity which can cut 30-60 minutes of debugging time. In addition to helping fix errors, which are just a part of the smart contract lifecycle, we also have a platform for monitoring the load on deployed smart contracts, and VMs for extracting data. We can help visualise the full execution cycle of all transactions on smart contracts, which can help developers see unexpected and strange behaviour on a method-by-method basis. This can help understand what is actually happening, and let the developer tell whether the contract is doing what it is “supposed to be doing”, or what it is “meant to be doing”.

AB: There are also tools for monitoring how smart contracts are behaving, who is using them, how money is being spent and how the contract is being used. This helps respond to unexpected behaviour, and identify entities trying to use it in ways that weren’t intended. We don’t just offer templates, the tool is highly configurable because the developer is in a better position to know what needs to be monitored.

CP: Beyond Ethereum, do you work with other blockchain networks currently?

AB: Currently we’re focusing on Ethereum as the ecosystem is the largest, but we’re building a platform to expand with Ethereum and eventually scale out to other platforms. In our view, in a future on ETH 2.0, it will be particularly important to monitor what is going on with smart contracts inside of Ethereum. We’re also believers in sidechains and permissioned chains networks. Projects like Polkadot and Cosmos also interesting for us.

CP: You were just in Berlin for the ETHBerlin Zwei conference, where you were one of the hackathon winners with your entry “sol.tty”. Can you tell us a) how to pronounce sol.tty and b) give us a brief explanation of what it does, and what inspired you to build it?

AB: Haha, I think that we’re going with “solty”, like salty, but with an “o”. We knew we wanted to do something with solidity and thinking of a name I thought of a TTY which is a term from the Unix world. Once we heard how sol.tty sounds, we couldn’t pass on the opportunity for a pun.

BH: Coming from the Web2.0 world we have experience with other tools for other platforms, and one of the things that we saw as missing in Ethereum was a REPL. Right now if you want to test a contract you need to write the contract, deploy it, call it, then destroy it. This can use a lot of gas and cost a lot.

AB: Our work on Tenderly has given us quite a bit of low-level operating knowledge of the EVM, so we decided to try to implement an EVM in the EVM. We spent about 40 hours during the hackathon with a table of the EVM opcodes trying to implement them in solidity. When you run a code it checks against the table and executes the method. You can then use a wallet like Metamask to run sol.tty and spin up your own local version of an EVM to check code before deploying it to the network.

CP: Let’s talk about how it can be used and the problems that sol.tty could solve.

BH: An example of where this might be useful is when you want to write a smart contract to arbitrage across multiple decentralised exchanges. Right now you’d need to query the DEXs, pulling from web3 and then implement the strategy to call the DEXs. But this means that you need to wait for transactions to be mined and the prices may have moved when you go to run your smart contract. With sol.tty you write the strategy in your wallet, ensure it works and execute it directly. In a way this now gives us some of the functionality that exists in Libra’s Move, where there are transactions and mini scripting programs that act as transactions. It allows you to orchestrate multiple smart contracts, and gives you more flexibility.

AB: We also implemented it as an identity contract, so that the functions can be called from a single contract acting on your behalf and allows you to control the originator of the call. This makes it cleaner to write code and add functionality later. It also allows your contract to do arbitrary things where the owner is an onchain entity.

BH: It is really flexibility to the extreme. It allows you to do anything that the EVM can do. We hope that it should open new functionality and allow people to experiment. We’ve looked at how it could be helpful for rapid prototyping without the need to deploy. You just run trials hammer at the end point. This might even be helpful for penetration testing on other contracts. Send a lot of tries at once and see what happens.

CP: So an EVM in an EVM is cool. Could you also do something similar for other VMs?

AB: In theory, and I stress in theory, we could do eWASM in the EVM but it is more complicated, or really go extreme and do a JVM in EVM but there would be lots of issues there and extra functions that wouldn’t really work or be necessary. For the eWASM in the EVM it might be useful for checking new eWASM opcodes to check support on contracts as well as the usefulness of implementing them.

CP: Could you talk to me about some of the challenges of developing sol.tty, and what you learnt?

BH: You can think of the EVM as composed of a few parts, stack, memory, storage and loop logic. Implementing the loop was easy, for-loops with switches. Biggest challenge was working in an environment that already had a stack without blowing up something. In theory it was possible to do it in one stack, but it was easier and more flexible to re-implement everything in memory.

AB: Our second issue was whether we would have corrupted memory. Initially we thought, “nah”, that’s not going to happen, but in the end, of course, we ran into corruption issues. Sectioning memory was something we constantly had to keep in mind.

BH: While implementing opcodes, a tricky problem to get right was positioning all data correctly on our stack. The EVM needs everything to have fixed widths, but sometimes appends values on the left, sometimes on the right. We had to go back to the GETH code to see how it was done. There isn’t a ton of documentation on it, outside of the Yellow paper which was a bit harder to decipher and would have taken too much time, so having a reference implementation was good.

CP: What’s next? Do you plan on further evolving sol.tty?

AB: It would be cool to continue to work on it, doing more optimisation on gas costs and adding more opcodes. It was cool when we arrived back in Serbia to see that we already got PRs for new opcodes. We’re just back so we’ve not given it too much thought but maybe we’ll look for grant funding to keep going.

BH: I’m interested to try having other languages for more defined use cases optimised for exactly what you’d wanted. This could make it easier for someone that doesn’t want to deal with all of solidity and could act as a bridge for what is executed onchain. Right now, without optimisation it isn’t really suited for using frequently because of the additional gas costs, but maybe this is something that could be brought down to say 5% more gas than going directly and might be worth using. It could also be useful for simplifying complex operations like swaps. Lots of transactions are straight-forward but others are a pain.

CP: Any other cool projects that we should know about?

AB: Check out Tenderly! We’re pretty heads-down focused there. Personally, I’m also interested in Uniswap because of its simplicity and flexibility.

BH: Decentralised identifiers are something that interests me personally. I also like the work around onchain wallets like Argent. The Gas Station Network (GSN) Alliance is also quite interesting because you can imagine how it brings adoption to the next level. Combine it with the iOS Shortcuts app to write code that is sent to GSN, and sol.tty. It would allow you to do walletless, gasless transactions from Siri.

CP: Alright, now you’re getting into sci-fi. Thank you so much guys, it was a pleasure talking with you. I wish you the best of luck, hopefully we’ll be hearing a lot more from you soon.

AB: Thank you, it was good chatting with you.

BH: Thanks for reaching out.