An Uncensored Look At Smart Contracts, Part 2:

The Journey to a World Unknown Begins in a Vessel Yet Built

If you haven’t read Part 1 yet, I recommend starting there first.

Getting started writing software is easy — just grab a popular IDE, write a few lines of “Hello, World”, hit that compile button and that’s, that.

Congratulations and thanks for readin — . Oh, wait, “there’s a bug”, you say? Don’t worry, that compiler you’re using probably printed out an intelligible statement and since you’re a quick learner, just go ahead and resolve it. Ok, I’ve really got to get goi — , huh? There was something weird in the byte-code your compiler spit out? OK, get familiar with a static analysis tool. Done? OK, see you lat — , oh? Now you want to deploy the application to your users? No problem, there are dozens of tools to help you with that. Anyways, have a nice da — , what’s that? You’re building with smart contracts on top of a nascent, decentralized architecture, such as a blockchain? Oh. I totally forgot that was the topic of this series. Well. . . go ahead and forget every tip I just gave you. Oh, and also, cancel your plans for the next few months, because things are going to get juicy.

Nascent technologies are hard. But probably not in the way you’d think. If you’re thinking, “these newfangled technologies are way too difficult to build because they’re complex and therefore inherently harder to understand”, then I’m calling you out specifically. In most cases, this has nothing to do with it. In all actuality, new technologies are just iterations on top of the shoulders of the giants which came before. Therefore, in most cases, they’re only as hard as the difference between this technological iteration, and the one which came before it.

No, nascent technologies are not perplexing due to their complexities, nor are they hard because of their inherent difficulty levels — instead, they’re difficult because they’re what exists between the stages of theoretical ideation (where education is everything) and a mass adopted technology (where design and interaction are everything).

In a technology’s nascent stage, its tooling and ecosystem are everything. To put it a bit simpler, nascent technologies are like IKEA furniture, but with one important distinction — when the furniture arrives, it comes disassembled with an instruction manual on how you might assemble it, however, the twist is that they forgot to include the tools, and there’s no customer service number listed. Good luck.

You might ask, “but what does this mean? I’m determined. I still want to build something using this”, to which I’d applaud. Assuming you’ve first adequately assessed whether the idea you have is appropriate for both smart contracts and a blockchain (or even a decentralized paradigm for that matter), there are at least three things more which should be on your checklist before you begin your journey.

1. Open source is everything. The first thing you need to find is a chain which was born of the minds of open sourced technologists. If you can’t easily learn from the experience of other projects, your journey will end in a desolate and deserted abyss. Even a blockchain’s permanence can’t save you here if it’s not maintained by peers — so make sure that you choose an ecosystem with community-driven software projects. Trust me, you’re going to need this one from the very beginning.
2. Adaptability. You’re going to want to find a platform which you can create adaptable and iterative products on. If you cannot adapt, then brace your idea for deprecation, loss of adoption, severe bugs, and subsequently the loss of your wife/husband and kids (only kidding about that last one… maybe). That said, tread lightly.
3. Standardization and growth are extremely important for newer technologies. Therefore the third attribute to assess, but definitely not the last, is whether a particular ecosystem is growing at a consistent rate with the rest of the world by keeping up with technology standards, design/interaction standards, and of course, security standards.

Finished? Great. You will probably realize that there are only a few choices remaining for you to take after satisfying the above constraints. However, if you’ve followed them carefully, congratulations — you’ve just saved yourself some time by separating out the “blockchain mirages”. Now you should pick just one of those, and settle in for a very long haul.

At Nori the choice was overwhelmingly easy: Ethereum. I’m happy to say that this one checks every single one of these boxes. However, this is definitely not the only choice, and so you should absolutely spend as much time as you need in this phase to pick the one which you think will be most appropriate for what you need. Don’t worry, the world will wait.

Toolsets and Developer Ecosystems

Now, about all this ruckus on the topic of toolsets and developer ecosystems. To be able to bring products from ideation to adoption, it’s key to have the capacity to rapidly prototype. If what you are trying to build can’t be iterated on in a live market, it will likely be forgotten and antiquated long before it can make its debut. Unlike specialized software where formalization is paramount, iteration is important in consumer software. To that point, if you need to spend the larger portion of your time building and tuning your own tools to achieve this, then you should probably revisit your checklist.

Now, if you, like us, have chosen the Ethereum ecosystem, then prepare to be amazed by the plethora of existing tools to jump start your process. There’s Solidity and Vyper for writing contracts, solc for compilation, IDE plugins for syntactic sugar, Embark and Truffle for rapid prototyping, EthFiddle to quickly write snippets, Remix for quickly testing ideas in the browser, Mythril for taint analysis, Echidna for bytecode analysis, web3js as an API into the blockchain, EthQL as a query language for the very same, and so many more. There’s even a simple tool I wrote that is compatible with a number of these toolsets (more on that in a forthcoming standalone post). Not convinced? I took the GitHub API for a spin to quantify Ethereum developer activity a bit more:

Here’s another on the growing total (stolen from @stefanobernardi) :

One further point, and this is paramount — participate and contribute to the development of all of the toolsets you depend on. Decentralized technology depends on it. Have an idea to improve on the tools you’re using? Reach out the the team behind it. Find a bug in the compiler? Submit an issue on GitHub. Know how to improve the efficiency of a common task? Submit a pull request on GitHub. Think some documentation can be improved? Update a readme. Think there’s a better way to do something? Create a new tool and ask for community participation. Remember, your creation is only as good as the tools that you can use to actualize it with.

Lastly, take a moment to remind yourself that nascent and open source technologies only achieve adoption when there is an adequate amount of collaborative developer participation. Unlike the decaying realms of proprietary software, where secrecy and intellectual “property” is everything, this is a radically different world where value comes from collaboration. But this power depends on a peer-to-peer world, including you.

Iteration and Versionability

Now this is a tricky one. Smart contracts are party to the blockchain construct — and blockchain has at least two attributes that make satisfying this requirement hard: immutability and a decentralized runtime. However, you almost certainly need this, even if only as a kind of training-wheels you can use until you’ve truly tuned it to where it will sit in permanence.

That said, the necessity of permanence of logic is often a fantasy and requires a mythical level of engineering aptitude. Logic permanence, unlike state permanence, is needed in very few real applications, and is seldom a good idea in all others. Some tend to shrug this one off as unnecessary. “Versionability?!”, they exclaim, “The whole point of a blockchain is to be immutable and logically deterministic”. I tend to disagree, and instead prompt extreme caution on how (and when) to leverage it.

No, Gru, that last bit doesn’t seem quite right..

An important realization, if you haven’t made it already, is that a blockchain is only historically immutable, and therefore so too are its smart contracts. What went in yesterday, stays there tomorrow and until the end the lifespan of the chain. However, they are certainly not immutable in present and future contexts. This means that as long as you plan for iteration, the determinism of your application is maintained, yet its execution location is made allowed to mutate (only in the present and future, and never in the past).

In slightly simpler terms, a smart contract without versionable capacities says, “I will always only do X when I see Z”, whilst a versionable contract instead says, “I will always only do X, which is told to me by Y, when I see Z” (where the X is the known smart contract, Y is the mutateable location of some versionable logic implementation, and Z is a transaction initiation). This is a controversial approach, as it reintroduces human-based trust and places an expectation that the maintainer of “Y” appropriately communicates and maintains upgrades. It creates “mutable immutability”, if you will. Tread lightly.

With versionability, it is key that the minification of logic determinism suffered is replaced by increased transparency and communication. More importantly, it’s important that it is implemented either as a means of application health recovery, or for feature extensibility. Utilizing this power to alter a smart contract’s logic, or a particular state therein which a peer is thought to have ownership (i.e., a token balance), can have dire consequences This is a decentralized technology after all, and as such, both third party applications, and peers, will frequently interact and depend on the consistency of your contracts, be it of a passive or active means (more on that another time).

You might be asking, “Well then, how?”. And if so, you can take a look at ZeppelinOS, a great tool for this task, or tread the frontier on your own. At Nori, we’ve decided to achieve this by adapting from a couple of popular techniques and then tailoring them a bit to satisfy a number of transparency requirements. You can look at the code here. If you’re interested in more on this topic, stay tuned, because there’s something hot baking in the oven.

Standards

“Technology standards? So boring, so bureaucratic. . . Who needs them?” You, dear reader — and they are now your lifeblood.

To be fair, technology standards in a centralized world make very little sense. Even at scale, a closed technology with routine and predictable users need not worry about formalizing or standardizing the way in which they create, build, or destroy. In fact, in that world, standards will at best serve as formal architecture; at worst, they are the butcher of innovation. But this is not the world you’ve chosen to be a part of, dear reader. No, you are the progress the world has been waiting for.

Schmoozing aside, standards are how we define the ways to interact with a technology. It is the architecture by which we, as a community, agree to be guided by. When we feel a standard is incorrect, we may propose a new one. They are what a user can use for an abstract understanding of a technology they are desiring to interact with, and they are a reference for understanding the design of the world around them.

However, standards are not rules, and they are certainly not law (and for nascent technologies this is especially true). Break them as you please; this is an important part of the process. They key difference between law and standard is its that, for standards, participation is optional.

For smart contracts, standards are what allow peers and third party applications alike to build in a way that can reliably and appropriately both interact and coexist with your application. Heard of and ERC-20 token? What about a non-fungible token? Well, these are a couple of the most popular smart contract standards, at least from the view of a token-based application developer. These standards define a number of function definitions that can be referred to for consumption by third-party applications. In fact, they are precisely what allow for the operation of almost every decentralized exchange and wallet today. Without this standard set of function definitions, and the subsequent number of implementations, decentralized exchanges, (and other types of smart contract-based applications) could not exist. Ever pull up an Ethereum wallet and see a list of tokens? The query-ability of that very feature is due to a shared standard. However, without a set of shared standards, actualization would be chaotically random.

Ready to begin?

For nascent technologies it is the iterability, standards, tools, and developer communities that are the fuse for adoption. For smart contracts, this fuse was lit long ago, and most recently it has largely been the Ethereum community leading the charge. This fuse does not end in a bang. No, this fuse ignites the launch of a marvelous vessel, one which can take us to an unknown world. It may very well be that this will be a place where applications can inherently interact with other applications, where data can be owned by its user, where identity can be sovereign and used across all applications, where permission-less participation is bountiful, where new markets emerge, and where the world is peer to peer.

Most importantly though, it’s also the very place where we can all breed digital cats.