Dragonfly + NEAR
Today, we’re thrilled to announce Dragonfly has made a significant investment in NEAR and is joining the NEAR Validator Advisory Board. We now run the third largest validator on mainnet, and we will work closely with other members of the NEAR Validator Advisory Board to support NEAR in its next phase of mainnet adoption.
Wait, what’s NEAR?
Glad you asked.
NEAR is a next-generation smart contract platform. It is the closest thing to Ethereum 2.0’s vision of a sharded scalable blockchain, but launched years before Ethereum 2.0.
Ethereum 1.0 can’t satisfy the increasing demands of decentralized applications. This first became apparent when CryptoKitties, the digital collectibles game, clogged the Ethereum network in 2017. Since then, the bull run of late 2020 has made Ethereum’s congestion problems even worse. Gas prices have soared to new all-time highs, while users have been desperate to trade and interact with smart contract-based applications.
We know this is only the beginning — DeFi applications haven’t reached mainstream audiences yet, but Ethereum 1.0 is already croaking under their load. Most DeFi applications that work on Ethereum today, such as AMMs and lending protocols, are all the more impressive because they work in spite of these constraints. But blockchain users and developers are demanding better.
This was all well-understood in 2018. At the time, the press branded rival smart contract platforms as the “Ethereum killers.”
The term has not aged well.
NEAR is not trying to kill Ethereum. At this point, Ethereum is going to forever be a fixture in the smart contract landscape. Rather, NEAR collaborates with and augments Ethereum, as another major city in the landscape of blockchain networks.
Right now there’s only one city that matters in smart contract land: Ethereum, which you can imagine like New York City. It’s where all the action is. But right now it’s crowded, calcified, and needs some way to scale.
There are, broadly speaking, three paths to scaling smart contracts. The first path is via “interoperability protocols” like Polkadot or Cosmos, which weave together heterogenous blockchains. These are kind of like building highway systems throughout the country, connecting a bunch of small towns.
The second path is via rollups, which you can sort of imagine like inventing taller and taller skyscrapers on top of Ethereum — not arbitrarily scalable, but a good short-term way to relieve congestion pressure.
The third path is what NEAR is taking: building a whole new well-governed and compatible layer-1 that can bridge back to Ethereum. In this metaphor, NEAR is trying to build a second city: the Chicago of smart contracts.
That’s enough metaphor though. Let’s get technical.
NEAR in a Nutshell
At a high level, there are two ways to increase a blockchain’s transaction throughput: vertical scaling and horizontal scaling.
Vertical scaling says: in order to achieve higher throughput, we’ll demand that each node is extremely powerful. This means that transaction processing can no longer be done by normal users, but it allows a network to process much more computation. Solana and DFINITY take this approach, which means in both blockchains, normal users cannot validate the blockchain on commodity hardware.
This is not necessarily bad! Vertically scaled blockchains can be attractive for certain applications that demand high performance and globally accessible, consistent state. But they do so by trading off against validator decentralization.
Horizontal scaling takes the opposite approach. Horizontal scaling divides up the system into multiple shards. Each shard performs only a subset of the total work on the blockchain, and each validator only needs to validate that single shard (and some “coordinator” shard). This allows many more users to participate in validation, due to the lower requirements per shard. This keeps validation decentralized, while still scaling the total throughput of the system.
This is precisely the vision that Ethereum 2.0 laid out: an arbitrarily sharded smart contract platform. Except Ethereum 2.0 looks to be years away — Vitalik recently claimed that smart contracts on Ethereum 2.0 will take so long, Ethereum has to go all-in on rollups in the intervening years.
NEAR takes the same approach as Ethereum 2.0: horizontally-sharded blockchain that can support orders of magnitudes more transactions per second. But unlike Ethereum 2.0, NEAR is available today.
To give you a sense for the sheer scalability improvements NEAR offers, each shard on the NEAR blockchain can process 10x more transactions individually than Ethereum 1.0. The NEAR blockchain will eventually have over 100 shards. This means that NEAR will eventually be able to process over 1000 times more transactions per second than Ethereum 1.0. Full sharding is not yet on mainnet, but even the current design is massively more scalable than Ethereum.
But scalability is, at this point, an easy promise. Many new smart contract platforms offer scalability, but users are still congregating on Ethereum. The real challenge is to create a first-class developer experience that outshines what Ethereum can offer.
This is where NEAR shines.
Some of my best friends are developers!
NEAR was built from the ground up to be developer friendly. Developers don’t need to learn a new programming language to get up and running on NEAR, thanks to its WASM-based runtime.
Are you a web developer? You can get up and running with AssemblyScript (a close cousin of Typescript). Or if you prefer systems programming, write your contracts in Rust.
Of course, the majority of developers in blockchain today already use Ethereum and the Solidity toolchain. NEAR will soon launch an EVM runtime within its virtual machine, which will allow Solidity contracts to be deployed onto NEAR with no significant changes. It also means Ethereum tooling like Ganache or Metamask will be easily compatible with NEAR-EVM deployments.
But what about assets? We all know the most popular cryptoassets today live on Ethereum, be it Tether, USDC, or DeFi tokens. Soon, you will be able to transfer those assets to NEAR via their trustless bridge, the Rainbow Bridge. Almost all of the cross-chain bridges in existence today depend on trusted asset custodians, but the Rainbow Bridge will be fully decentralized, protected by cryptography and incentives, rather than by trust.
There are many other great UX improvements within NEAR. For one, human-readable addresses — instead of a name like 2e75ed2ffaae39e859b6…, you can transfer your funds to us at dcp.near. This is all implemented directly at the protocol layer. You can even have multiple names owned by the same public key, or subaccounts nested within another account (like haseeb.dcp.near).
There are many other fascinating aspects of NEAR’s design, such as their implementation of EIP-1559, contract-level developer rewards, and storage staking. But NEAR is still a young network, and we expect it to evolve with the next generation of crypto applications.
But succeeding as a layer-1 requires more than just technology.
Great blockchain platforms are ultimately built on their communities. NEAR’s DNA comes from its founders: Illia and Alex, both extremely capable and practical engineers, hailing from Google and MemSQL.
Through NEAR’s focus on UX, for both users and developers, they have brought together a world-class team and vibrant developer community.
Alongside the trove of introductory developer tutorials, there are many projects building on the NEAR network through the Open Web Collective.
NEAR has achieved promising traction so far. But it’s still a young network and has much of its roadmap left to deliver. The next few years will ultimately tell whether its momentum will solidify its place as a dominant smart contract platform.
Get Involved
If you’re interested in learning more about NEAR, you can join the NEAR community on Discord or Telegram.
If you’re interested in participating in the network, you can check out the validator guide here.
Or, if you’re a developer, check out tutorials and examples here. Happy hacking!
Major thanks to Ashwin Ramachandran and Ivan Bogatyy for their contributions to this writeup.
