Replies: 5 comments 2 replies
-
Thanks for this, @chadoh! It's pretty eye-opening! We'll be reviewing submissions and offering rewards starting next week, and I'll ping you here with more info once we do. In the meantime, let me know if you have any questions. I definitely encourage you to submit again if you're interested as well. The more feedback and insight we can get at this stage, the better. |
Beta Was this translation helpful? Give feedback.
-
Interesting!! I'm wondering what the comparison would look like with a more complex contract. |
Beta Was this translation helpful? Give feedback.
-
Great write up! I too would be curious how this stacks up for a more complex example. I would imagine though this is largely due to the standard library not being excluded on the Near side? Is it possible to do that or do things break? For more complex contracts would the exclusion of the standard library eventually come back to bite you as you pull in standard libraries piece meal? I guess the real question is how significant is this comparison when expanded out to more common contract use cases? Either way it's great to have you and thanks for a great submission! |
Beta Was this translation helpful? Give feedback.
-
Heya Chad, Great piece BTW! Can't wait to see you keep tinkering with Soroban and documenting your finding! Please let us know if you have any questions. (You can also message me on discord @ anuxhya) All the best, |
Beta Was this translation helpful? Give feedback.
-
You know, 99KB to 477B isn't a fair comparison. That NEAR contract was completely unoptimized. What's the size of the NEAR contract if we run the same optimized build settings as the Soroban contract? This branch of RAEN adds those same optimizations to 477 bytes to 64 kilobytes is still more than a 100x size difference, though! Why are NEAR contracts so big? More on that in #26! |
Beta Was this translation helpful? Give feedback.
-
The code in this NEAR codebase has similar functionality to Soroban's quick start contract, so I could compare contract sizes using NEAR's suggested defaults vs Soroban's.
Here's the Soroban code:
Here's the NEAR code:
The Results: Holy contract size, Batman!
Soroban's contract size:
NEAR's contract size:
Soroban contracts are 3% the size!
NEAR smart contracts built with Rust are big for two main reasons:
std
, the standard library, which Soroban requires you skip (see that#![no_std]
?)I know there are ways to avoid both of these with NEAR smart contracts, but the only people I've known to attempt it are Rust experts. Soroban seems like they're trying to give all developers this superpower by default.
But it doesn't end there!
With just some build process changes, you can build an optimized version of your Soroban smart contract:
3.3 kilobytes wasn't small enough! Had to make it about 10x smaller yet.
Damn, y'all. Settle down.
Is there any future for Stellar, though?
I met someone from the Stellar Developer Relations team while at NEARCON. When I mentioned Stellar to a NEAR maxi, he said something like "Stellar's not going anywhere, though."
I mean, maybe?
Stuff I like about Stellar:
Stuff that's interesting about Soroban, their new smart contract platform:
uses Wasm
focused on Rust
creator of Rust on the team??
(also, yes, that's a screenshot of an issue where they're considering switching to WIT, inspired by my team's work on RAEN 😊)
contract interface / ABI added to the Wasm custom section, RAEN-style, by default, so that Every. Single. Contract. will have fully-typed interfaces discoverable by all developers on the platform, right out the gate.
event system baked into the protocol, also right out the gate (NEAR could have used this!)
sometimes being late to the game is an asset: can learn from existing Rust & Wasm blockchains, taking what works and tweaking what doesn't
those contract sizes!
So I dunno, Soroban & Stellar don't seem doomed.
Beta Was this translation helpful? Give feedback.
All reactions