Learning Solidity for Attorneys

Learning Solidity has long been an aspiration of mine that, until recently, seemed simply too imposing for someone whose coding experience was limited to occasional web dev from several years ago (most importantly, zero Javascript, C++ or Python—languages from which Solidity borrows syntax and structure), and for someone whose primary use of semicolons is to enumerate loan and lease conditions or covenants, rather than to close a statement in a programming language. This spring’s/summer’s COVID-19 quarantine conditions made me try it anyway, and thanks to the structure of the 100DaysOfCoding challenge framework (basically, just code an hour every day and keep a journal) and the help of some more advanced and generous coding attorneys in LexDAO, I feel it’s been a great success.

So, I thought it may benefit some in similar hesitant positions to have some tips on how to approach Solidity as a noob, and some parallel considerations with legal agreement drafting for those also masochistic enough to go to law school. The resources I used can be found here.

First, some of those parallels:

·         Solidity and law are both infrastructural core frameworks that sit as executory rules until invoked or called during a transaction or enforcement of a condition or rule.

o   Front-end / user experience (with respect to Solidity) and commercial/business-side concerns and preferences (with respect to legal agreements) must be contemplated throughout the coding and contract drafting processes.

o   More simply, the realities of the contemplated transactions and the parties’/users’ goals and potential uses influence the chosen frameworks. It’s inefficient to progress either side independently.

·         Coding and law both rely substantially on precedent, but small tweaks may result in massively different outcomes, and a single bug or loophole can destroy the entire codebase or agreement. A big difference is that coding outcomes can be modelled on testnet, and thus allow a bit more active trial and error in the initial stages of coding on Ethereum.

·         In Solidity, it’s important to remember that backwards (and forwards) compatibility and any corresponding limitations should be taken into account (or more subtle differences in language versions, such as gas costs or variable typing), and it may be necessary to account for a smart contract’s ‘upgradeability’ or ability to snapshot/deploy a new instance in the event of a hardfork or bug. Similarly, legal agreements must account for statutory, regulatory, and common law changes as well as the agreement’s amendment, supplement, or assignment.

·         Choosing a Solidity version and any imported files or libraries is somewhat analogous to choosing a governing law and invoking uniform standards, such as referencing UCC remedies, or statutory term definitions. Often there’s no reason to reinvent the wheel: using commonly-referenced and audited libraries or forms is good and efficient practice.

As to my #100DaysOfCode plan, generally my workflow was starting with tutorials that slowly increased in difficulty (repeating some more than once), until I started guessing the next step in the tutorial given the prompt. Then, building simple smart contracts and gradually increasing the complexity.

I spent almost all of my time in Remix: an interactive development environment—for those unfamiliar, this is an all-in-one code, compile, deploy, and test interface. I preferred Remix’s (i) succinct built-in error messages, (ii) easy/intuitive compiler and interface, (iii) options to use a Javascript virtual machine test environment (no mainnet or testnet ether needed), testnet, or mainnet all from one interface, and, perhaps most importantly, (iv) the dark mode and satisfyingly vibrant-colored syntax highlighting aesthetic, let’s be honest.

Five general tips I have for learning Solidity from zero:

1)      Set out basic long, mid, and short term gameplans, with some concrete milestones.

2)      Collect and preposition some reference materials and tutorials you think are most interesting and relevant to your purposes, to not lose momentum when you’re unsure which direction to go next.

3)      Much like unfamiliar/new legal concepts, a well-crafted general search can yield extremely helpful context and examples. From there, you can further hone platform searches: much like Lexis / Westlaw / etc. on the legal side, StackOverflow / StackExchange / Github have troves of useful materials and commented explanations.

4)      As mentioned above, noting some parallels in drafting and coding helps with absorption and synthesis of ideas:

a.       import is analogous to incorporation by reference

b.      declarations are similar to contract recitals

c.       modifiers are similar to restrictive covenants

d.      generally, the importance of narrowly defining calculation/oracle mechanisms and third party restrictions, and

e.      Solidity version choice is similar to governing law, upgradeability is similar to amendment/supplement, etc.

5)      After getting the basic practices down, work in efficient syntax (analogous to avoiding unnecessary legalese), helpful commenting, easy gas improvements and necessary restrictions (for example, declare a function as external if the function will only ever be called by an external address, private to only allow calls from other functions inside the contract, internal to allow internal function calls but also calls by contracts that inherit from the one at issue, and public if the function may be called by any of the above).

I’d love to hear any feedback from fellow fledgling Solidity students. If helpful/interesting to anyone, I may do a deeper dive into Solidity concepts/constructs with legal significance, for example function modifiers that restrict access or ability to control certain amounts or actions, autonomous conditions precedent triggers, etc. The LexDAO discord is a great place to bounce ideas off others and seek some other resources and tips beyond those posted above.