Thoughts on the Solana Blockchain
The black box of block chain technology
Solana is a blockchain platform launched in 2019 that has a native token SOL and allows for smart contracts. At time of writing, the native SOL token has a market cap of ~ $42 billion, making it the 6th biggest coin by market-cap and Solana the 4th biggest blockchain platform after Bitcoin, Ethereum and Binance Smart Chain (BSC).
The claim
Solana markets itself as a more scalable cheaper alternative to Ethereum. At time of writing, its website claims more that 1,600 transactions per seconds with an average cost pre transaction of $0.00025 and 1,372 validator nodes.
It’s able to do this because its blocks are 400 milliseconds (compared to 10 minutes for bitcoin, 13 seconds for Ethereum and 3 seconds for BSC). Solana is not compatible with Ethereum Virtual Machine (EVM), the abstraction layer between smart contracts and the underlying code. Instead, Solana compiles smart contracts using Rust.
Transaction fees are obviously a big problem with Ethereum, and the high cost led me to playing with BSC instead. But presumably Ethereums high fees will be alleviated with 2.0 and BSC is just a clone of Ethereum and feels kind of scammy. So I was excited about looking at what development on Solana looks like.
Interacting with Solana
I’ve been told going from Ethereum to Solana is like going from 56k modem to broadband. I was even able to transfer tokens from BSC to Solana through Wormhole token bridge. And Solana was easy to setup on my computer with Solana CLI. With BSC, I mostly interacted with the blockchain using web3 or remix IDE. Getting rust setup was simple enough as well.
The list of decentralized apps on Solana was uninspiring, mostly a rehash of everything I found on Ethereum and BSC. It was token exchanges, AMMs, sketchy token staking and NFTs. But I thought Pyth had a lot of promise. Pyth is an oracle of many financial assets, bringing real time market data to Solana. Due to the cost and block size intervals, this is impractical on Ethereum and BSC, but with Solana it’s a natural fit.
Interacting with a Solana smart contract through Phantom looks like this:
There’s no address of the contract. If you click view additional details, you’ll see that it creates an account, transfers SOL, initializes the account, transfers SOL again, approves, unknown, and then closes the account.
The wallet doesn’t even let you see the program id (even if you hover over it), which is kind of important. And you’re sending a blob of data. Compare that with using Metamask for Ethereum or BSC.
You’ll see the address in the top right. You can also see the method (swap exact eth for tokens) and the data you’re sending over.
If you take the contract address, you can go to bscscan (or etherscan for Ethereum), and see the contract. There you can find every transaction ever sent to the contract as well as the contract code. You can even interact with the contract from that site and read contract data. Solidity contract code is relatively simple to read and complexity is strongly discouraged due to the cost of bugs in immutable code.
So what does solanascan look like? It’s indicepherable. Sure you have transaction hash and some vague semblenace of inputs, but you have no idea what’s going on.
But the most bizarre thing is that you don’t have access to the source of the contract or signatures. You rely on the client app telling you what to call and how to call it.
You can’t access a Solana contract’s source code
It never crossed my mind that the 4th largest blockchain would not allow you to access the contract code. To be fair, on Ethereum and BSC you also upload compiled source, but the complication is deterministic. So its good practice to go to bscscan (or etherscan) and upload your ABI and source and specify your compiler version. Then it will be recompiled and compared to the source on the blockchain. If they match, the source is hosted on the site and you can be assured of the contract source.
But with Solana you can’t do that easily, because the compilation may not be deterministic! From my understanding, the dependencies aren’t pulled deterministically. This was a design decision. There was probably a meeting where they had a list of pros and cons of various alternatives on a whiteboard. And one of the cons was “you can’t easily see the contract source or tell how to interact with the contract”, and someone said, nah, that’s fine!
To be fair, technically it may be possible:
But for some reason Solana dev team doesn’t see it worthy of promotion and building out tooling to make this easier. They don’t seem to care that there exists “a surprising amount of closed source apps”.
This made me chuckle:
As far as I understand, this matches the situation on Ethereum - except Ethereum has a centralized third party (Etherscan) facilitating this process by allowing authors to upload their contracts, which Etherscan then builds and verifies against the on-chain contracts
Solana explorer is a centralized platform similar to Etherscan that’s hosted by… checks domain… Solana! So why don’t you implement it or make this easier? Is transperancy into the contract you’re sending money to not as important as some tweak to associating jpegs with addresses?
In Ethereum and BSC your contract is often times a single file and you can just paste its code directly on the relevant scan site, select compiler version and be done. They even have decompilers. I personally would never interact with a contract whose code I couldn’t inspect. Solana team and users are fine with a black box, which is … odd?
And that’s where my exploration into Solana ends. I hope I’m wrong or missing something because this is the leading candidate for alternative to Ethereum Virtual Machine. They have a lot of problems around centralization and stability, but I was optimistic and think there’s room for multiple blockchain solutions.
But how could anyone be okay with an ecosystem of black boxes. I never thought to consider this because of course you’d have access to contract code. That’s kind of the point of blockchains. It’s not an unsolved problem. Ethereum solved this problem and gives you full transperancy into the code you’re interacting with.
It’s troubling to think that the 4th largest blockchain would have such an obvious fundamental flaw. It makes me more bearish on the ecosystem as the “market” has decided this is the best competitor to EVM. I get it, worse is better, but come on.
"They have a lot of problems around centralization and stability..." this almost doesn't make sense : ) They're a centralized "blockchain", yet even so have problems with stability. My Hetzner VM hasn't been down in years.