That’s it! While it may not seem like much, you’ve now written a rudimentary Ethereum smart contract that can be initialized with state, that holds, receives, and distributes monetary value, and that exposes the ability to determine financial account standing. While none of these concepts were implemented with security or completeness necessary for production use, they demonstrate key functionality that give Ethereum smart contracts their power.

Real-world considerations

The tutorial above is useful for introducing Solidity concepts and showing them in action, but developing and deploying real-world smart contracts meant to be used in high-value business exchanges requires careful planning and consideration.

The basic cell phone subscription contract we codified is inherently insecure and could be greatly improved. For example, funds withdrawal should be restricted to a set of pre-approved sender addresses to prevent arbitrary users from emptying an account. As it stands now, anyone could call withdrawBalance and receive all ETH stored in the contract. Further, the makePayment function could be augmented to validate the received payment to prevent overpayment or underpayment, and the sender could be verified to be from a known account, if desired.

While the Remix development environment is great for prototyping Smart contracts and testing Solidity correctness, most real-world smart contracts would be developed locally using more complex build tooling such as Truffle. Perhaps most importantly, it costs real money in the form of ether to interact with smart contracts deployed on the main Ethereum network. This is by design, and forms the cornerstone of Ethereum’s economic self-sufficiency: it costs money to do anything on the live Ethereum network. Thankfully, Remix bypasses this initial complication by spinning up an in-browser, JavaScript-based EVM that mimics the behavior of the real network EVM. In practice, smart contracts would be deployed using Node.js-powered CLI tooling through a framework like Truffle, and both deploying contracts and calling functions on them would require an Ethereum account funded with real ether.

Conclusion

The practice of authoring smart contracts requires both programmatic knowledge of Solidity semantics and knowledge of the tooling surrounding both Solidity and Ethereum in general. The level to which concepts are abstracted and the overall Ethereum developer experience have both improved in recent years, and it continues to do so at a rapid pace. Ethereum has established itself as a mature smart contract platform with an impressive feature set and strong community backing. The question of whether businesses have both an appetite and a true need for such automated contracts remains to be seen.