Writing

Having run and worked on blockchain infrastructure for some time, I naturally have come across a lot of things I want. As someone who dabbles in smart contracts, there is a lot left to be desired by blockchains today. To me, this all feels obvious, but I don’t see any ongoing discussions about these things. 

I think plain old web 2 developers would really be able to dive in & be productive with blockchains much faster if we had these things.

Every hackathon I have been too on behalf of QuickNode, I have met someone who is a good web developer but has no idea how to write solidity! Compound this with the fact that many languages are not statically typed, and you quickly see that tens of millions of developers are expected to jump in the deep end of the pool to just get started. 

If there was a way for PHP/Python/Ruby/Perl/JS developers to just write a script in their favorite language that has certain constraints, put it through a transpiler & have a smart contract with its associated ABI as well as client library with appropriate bindings come out on the other side - I think we would see a ton more adoption of blockchains!

Any time I have ever onboarded a web2 developer to web3, after we get over the hurdles of not being able to write smart contracts in their favorite language, send http calls in smart contract in a straight forward manner, and dealing with wallet/account infra to create/sign transactions they wonder why their transaction is not settling quickly!

I have used Base, Optimism, Ethereum, Bitcoin, Arbitrum, etc, etc & quite frankly the UX of waiting more than 1 second for a transaction to finalize / be included in a block is dog shit. Solana is the closest thing we have (at scale) to HTTP like block inclusion times. 

As a web2 developer, I expect things happening in my app to be definitively concluded in 200-800 ms. This is a hard feature to get live, but man is it high up on the wishlist.

I think a better term for this would be in-transaction HTTP calls. I deeply want the ability to make HTTP calls from my smart contract code. I'm fully aware of Oracles, but I do not think they're a great solution. I think there are a few challenges here, however I think to get the idea juice flowing, here's a thread to pull on:

If there were some zk-based API authentication, then validators/miners could send the HTTP call without having to make API credentials vulnerable. Additionally, if the miner/validator that includes the transaction makes the HTTP request, they can theoretically store the request/response in the same way that VCR does for testing in ruby so replays can be done easily.

I really think this is a huge opportunity for anyone trying to build an L1 and I hope someone invests time on solving this very hard problem.

This is kind of an esoteric feature request, but if we could get a spec on locking for basically everything on smart contract capable blockchains, that would be fantastic. I say this because constantly validating or maintaining a copy of a blockchain is not really tenable for certain situations. Consider a situation where a phone that has limited service needs to be able to prove that they have a particular token (like a blockchain based passport, driver's license, etc) for some reason (like entry to a new country, being stopped on route 66, etc). If there is no service, then whoever needs to do the verification of authenticity or ownership is cooked.

I think this is actually pretty crucial if we want to do anything valuable with blockchain in the real world. So yet another blocker to mainstream adoption. I'd love to see an EIP on this. Please DM me if you're working on this!

For those unaware, every smart contract that is deployed is stored in some compressed or compiled format that is not easily deciphered unless you have what is called an ABI (for EVM based chains) or IDL (for Solana). These data structures allow you to easily bind your programming language of choice to the smart contract for simple and quick integration. Ethereum pioneered this idea, and it's actually super awesome, but they didn't take it all the way.

The fact that these are not widely recorded onchain is a failure in my opinion. We can't have an open world if everyone is holding their ABI offchain. Putting them onchain would allow for maximum discoverability, and be better for anyone and everyone trying to build integrations.

UTXO transaction models get this by default but EVM account models lack this. Again this is kind of off the beaten path, but Solana gets this one right. I didn't actually realize how powerful and useful this is until I saw how Jupiter swap API makes use of it. Basically, sending a transaction on an EVM allows the externally owned account (wallet) to send a fixed amount of a single token to a single recipient. If you want to send different amounts of a token to different recipients, you need to either use a smart contract or send multiple transactions, both are suboptimal.

Parallel transaction processing as i've seen it in Solana allows for that to change, any number of tokens, in any amount, to any number of recipients - provided you're under the maximum instruction limit. Very awesome.

I'd love to see EVMs find a way to make this possible. With 7702 on the horizon for Pectra, it may be here sooner than most people think.

I know this wishlist might come off as me complaining a bunch, but as a developer who wants to build smart contract enabled stuff, my hands are tied by the protocol / blockchain I choose. It’s clear to me that to get more developers on board, the technology needs to meet them halfway—making it more accessible, faster, and versatile.

If you work on blockchains or blockchain clients and want to rap on any of these ideas, I'm more than happy to chat! Just send me an email or a DM on tg!