AMA with Aurora Engine Team Lead Joshua J. Bouw
On November 23 Joshua J. Bouw, Aurora Engine Team Lead, held an AMA session in Aurora Dev Telegram group (https://t.me/auroraisneardev). Here's a recap of what has been discussed, what the developer community asked, and what Joshua talked about.
Q: Let's start with an introduction. I know you have an exciting background. Please tell us about when you joined blockchain, why, what you did and how you ended up in Aurora.
A: When I joined the blockchain space, wow. Unofficially, after the Wired article about WikiLeaks accepting Bitcoin (2010?) and me figuring out what it was. Tinkering around with Bitcoin, trading it in Second Life (only place you really could do it at the time) or trading it for Diablo 2 legendaries hah!
I primarily joined it because of just an immense interest in the field. It was clear that there was something very special with the blockchain space which was unlike other fields. A lot of people at that time are not really around anymore surprisingly because they mainly liked it when the community was small.
I'm more so known primarily for kicking off the Proof of Stake revolution at Blackcoin in 2014. We had countless people cloning the project, and others have really taken it to the next level in ways that we hadn't predicted back then.
I ended up with Aurora through mutual aquaintences and my background. Arto relentlessly hounded me down until I returned his e-mail, and the rest is history.
Truth be told, I felt like a monkey discovering fire in 2010. I poked the fire with a stick and got burnt and thought I destroyed my PC with mining and didn't touch it for a few months. I'm glad that I stuck with it though.
Q: Haha yeah this does sound like an adventurous journey for you! Looking at it now what do you think about Ethereum, NEAR and blockchain in general? What future is awaiting us and why would one want to join it?
A: For the longest time I was never a large believer in account based systems, I love UTXO, though these days I will say that I do prefer account based system in NEAR. I'm also not a fan of Nakamoto-style consensus which Ethereum inherited from BTC. Ethereum understandably was an important first step in the smart contract revolution and it did take me quite a bit of time to warm up to it. But admittedly, it wasn't until after learning about NEAR and what it can do that it felt just right. And thats after looking at countless projects. NEAR really sparked excitement in me because it had well thought out and developed solutions that many other projects had been stumbling over.
The blockchain space right now is hyper crowded with a lot of projects competing for users and that will never change. It will be those that really stand out that are going to make it in the end because years of doing this, I've seen too many under-developed but well hyped projects eventually collapse in on itself. NEAR to me I believe is able to outlast any other project currently on the market apart from ETH and BTC. There is just so much more capacity on it and it truly has realised the vision of ETH 2.0.
People should join the revolution, and law makers have got to understand it. It isn't just about "making money" but its about making totally government resistant and inclusive financial systems that do not care who you are.
I believe everyone has a human right to access financial systems freely.
Q: This does explain why you eventually decided to join Aurora, although I am sure you had lots of other opportunities. I believe everyone pretty much knows that we are a NEAR spin off.
Tell us about your perspective of Aurora. I know you deal mostly with EVM. What is your work about? Do you have any challenges during the development process? What technologies, languages you employ etc.
A: My work is about leading a team to create a 1:1 EVM implementation but also taking that a step further. For example, we want users to be able to pay for gas fees in ERC-20 tokens as we have this detached relationship of what it means to be a blockchain through the relayer. Those gas fees could essentially be anything provided a relayer accepts that currency. That is a challenge, but one that we have solved and need to implement.
Obviously the number one challenge is ensuring that our work is completely on par with Ethereum. The second challenge would be to completely redefine user experience but stay faithful to the EVM. As in the example of paying gas fees in ERC-20 tokens above!
We primarily stick with Rust in the engine, we do not really see a need to use other languages and Rust pretty much can do everything from websites to video game engines.
For the technologies, Michael and I are both contributors to the rust-blockchain EVM, which is a faithful EVM that we are built upon. We have contributed numerous improvements to that including the London and Berlin hardforks which were quite a pain to work in and deliver it correctly. The Ethereum provided Json tests can fail, and it can be quite difficult to determine why it failed, leading to many days of debugging.
Actually, I should mention that our largest challenge currently is increasing the gas capacity per transaction with the NEAR developers who have made amazing progress. With the recent blockchain upgrade on NEAR, we are able to do roughly 2x more than we could before per transaction! This will only continue to improve as we believe we can make this even better.
Q: It's encouraging to hear that we are improving and reaching our goals. And it's happening at quite a fast pace. Since this session is aimed at developers, why do you think it's beneficial for them to build and deploy projects with us? Why are we a better choice? Why do you believe they will have a better experience with us?
A: To put it simply, read up on ETH 2.0 goals and why everyone is excited for them and how it would effectively solve many things in the Ethereum ecosystem. Now understand that exists -today- with gas prices and everything -in Ethereum- on Aurora. And a seamless trustless bridge experience.
It really is a no brainer to move on over. Its the same tools, same EVM (with improvements), cheaper, faster, more capacity, sharded.
Q: Before we open up this session for questions, are there any links/resources that you would like to share? Maybe something interesting from our Github? Any code snippets? Whatever you think may be particularly useful, if anything.
A: I never thought about that. I mean simply our world is here: https://github.com/aurora-is-near/aurora-engine/tree/develop in the develop branch of the EVM.
Another library of note which other projects also use is what we call "Sputnik EVM", now renamed simply as rust-blockchain EVM" https://github.com/rust-blockchain/evm of which both Michael Birch (@birchmd) and I are contributors to.
It is worth noting that we are working on compartmentalising the Engine so that we could effectively use it for other uses such as debugging transactions so that we do not have to go through opcodes by hand to figure out where our largest gas costs are, and where issues might arise in a transaction: https://github.com/aurora-is-near/aurora-engine/tree/develop/engine-standalone
Q: What is your vision of smart contracts v2.0? What are the natural evolution of smart contracts and EVM in next 5 years? What features do you anticipate?
A: Smart contracts future is in WASM, imo. The way that NEAR had done their contracts is quite beautiful. Its is incredibly seamless than other blockchains that also do WASM contracts, and thats speaking from experience! Previously, I had worked with Aleph Zero (I think they just went live?) in Substrate and it was truly a challenge and felt kind of awkward.
Q: Considering the pace of Solana ecosystem growing and other L1s do you plan to add more bridges in near future? Like, bridging Solana token standard + NFTs...and the same for other prominent L1s.
A: To other EVMs? I don't think it had been fully discussed internally, but I believe this may be a direction we will head to. No plans besides talks here and there about other EVMs.
Right now we are making the bridge and connection to ETH fully seamless. In theory, we could do something like a bridge to BSC and the relayer for that could charge gas in BSC. All in our single Aurora EVM.
Q: Do you consider adding subscription based access to remove the gas fees overhead for the users?
A: It's funny you bring that up, I had spoken to the CEO (Alex) about that earlier today. So, hypothetically there could be a relayer that say, you pay $500 by credit card to, and get access to unlimited transactions.
I don't believe that is on our radar, but anyone is able to spin up a relayer and provide that.
There is a potential that we may provide that too. I wouldn't say that we wouldn't look into that especially given we are having internal communications about that.
Q: I was playing a bit with Aurora and was a bit confused with the RPC architecture. As I understand the Aurora architecture, the only way to submit the new blocks to the Aurora mainnet is by using the relay.aurora account (according to mainnet.yml config https://github.com/aurora-is-near/aurora-relayer/blob/master/config/mainnet.yaml). Will the Aurora be centralized around the main RPC that could only submit the new blocks? Will it be possible to submit new transactions via self-hosted RPC?
A: Its not centralised around just our relayer. Its possible today to host your own relayer. Internally, we do pay the NEAR gas fee, so other relayers would too need to pay the NEAR gas fee themselves. It just isn't convenient right now because we still need to add the functionality for relayers to SET their gas price.
Q: Love what you do with Aurora. Tech is great, but what about the user base? Is it hard for people to trust bridges and move funds over to Aurora? Do you see the bridge as a big turn off for users willing to buy an NFT or trade on L2 instead of L1?
A: Our bridge was built up to be totally trustless. Even we can not make any changes to it. There is no single account that has access to a large pot of funds which is privalent in other bridges. I don't know if I understand what you mean with the second part of this question.
Q: Can you talk about Aurora’s future plans for NEAR interoperability?
A: Yeah, this is something that we want to do. I'm not sure if we can squeeze it in by the end of the year though. We currently have a high priority of launching the engine as a standalone service which hopefully will be completed by the end of next week, then gas fees set by relayers in whatever token after that.
Q: When can we expect to be able to pay transaction fees with ERC20? Does that mean I can pay tx fees with wNEAR and I don’t even need to hold any Aurora ETH?
A: There is urgency to get this done. Internally all the work is there, but we just hard coded the gas fee to be 0 for now to incentivise people. Yes, you would be able to pay tx fees in wNEAR if the relayer accepts it.
Q: How are you approaching bridging of NFT-a? Will I be able to bridge Aurora native NFT-s to NEAR and Ethereum at some point?
A: Yes, at some point in the future you will be able to bridge assets to Ethereum. Not sure about NEAR, but should also be possible.
Q: Considering sharding capabilities of Near do you expect a big wave of people to come and test their apps in Aurora EVM before eth 2.0 migration? How do you plan to cope with potential load?
A: We do expect a surge of people to come over and try out Aurora before ETH 2.0. We are mostly tackling the load by scaling our relayer and will be implemented development keys shortly. Right now anyone can use it and we have had some "fun" because of that. I do fully believe that NEAR can handle the transactions though.
Q: Are there any recommendations for developers that want to deploy on Aurora? Any errors/misconfiguration that you noticed previously? We already have some projects running on Aurora. How has the experience been with them from the developer standpoint?
A: Most projects have run into gas issues, but I believe they are all unblocked right now. There still is an edge case or two, but its been quiet since the NEAR protocol upgrade. The rest of the issues had mainly been on bridging, but I don't see those kinds of questions. The ones that make it our way are mostly gas related, then we end up going through the tx opcode by opcode to see where it fails. Lengthly process, but won't be an issue soon.
Q: How is the load right now? Do you see a lot of people bridging their ETH to Aurora, can you maybe share some stats?
A: Load right now is quite bareable. I think the bridge has roughly $130 million in assets right now. That certainly couldn't gone up more. We do have a stats page although it may be missing some data and be outdated. Anytime we get overloaded, we just increase our overhead 10 fold 😄 Luckily we got some of the best infrastructure guys that are able to fix that.
Q: Why are we not having projects pop-up on the ecosystem? Are developers facing problems launching or developing their projects on Aurora?
A: This is more of a personal opinion, but I think a lot of people on Ethereum got fed up and split onto Avalanche. I don't believe its because developers are facing problems launching right now. If so, I would love to know so that we can work on fixing that. We don't exactly believe in that philosophy, which is why we stick with ETH as our base. We are incredibly proud that we have done so. In other words, we want to compliment the ETH ecosystem. Not compete against it.
Q: I'm a very big believer in the Aurora ecosystem that's why I am putting every effort into building the ecosystem. Hope to see more developers incentives from Aurora. I run the Aurora Community group based on pushing Aurora and I would love to be able to speak on the Incentives to developers.
A: We will have a great deal of incentives :). We just are not there yet. The bridge in the way it is now, I don't see how it could be possible though. Perhaps end of Q2, and we got everything running well and our goals are complete, maybe it'll pop up on the radar. I'm unsure. I don't know what is public about the incentives yet, and it would come down to the IDO Aurora holders. Not Aurora Labs itself. So, while we could say "We want to do X" it would simply be a proposal, and everyone votes on if they want that, or not. So you'll hear the word "maybe" a lot, because at the end of the day, it needs to be voted on. IDOs are truly a community project. I'm so sick of projects that simply listen to the almighty omnibenevolent team to be honest. I'm sure that the community heads will certainly make the process to initiate a vote known, and the website team likely will include the FAQs on that process. They are really good at that.
Q: Do you plan to reduce finality time for transactions? Do you have a room for optimizations in that regard?
A: We are limited by NEAR's protocol
Q: I know we joined Hackathons in the past. If you have any feedback/observations about it, please share (code wise, not incentives wise). It may be useful for future contests.
A: I think we learnt what not to do. The last hackathon none of us really had time to actually sit down and thoroughly go through possible problems. We ended up choosing some really hard issues that nobody ended up tackling :'(. I think it was related to calling NEAR contracts in Aurora?
Q: Would it be possible for me to cover all transaction fee costs of users interacting with my contracts? How would that function technically? I have to run a relay? Maybe as an incentive for users to join the product etc.
A: I don't see why not. I think you would need to alter our relayer to ensure that calls are in fact targeting your contracts. Then just not charge a gas price. But yeah, you would need to run the relayer yourself.