Smart contracts are part of web3 and are small programs that run autonomously when predetermined conditions are met. If you are new to web3, I would suggest checking out this blogpost highlighting some of the common terms. These programs are generally short (less than 500 lines of code) and are stored entirely on a public distributed ledger like a blockchain. Anyone can view the source code of the contract and verify it does what it's supposed to do. Smart contracts, once deployed are immutable and unable to be changed.
Smart Contracts primarily written in a typed programing language called Solidity. Solidity files have the .sol extension. An example can be viewed here. Solidity developers are in very high demand and I recommend learning about the limitless opportunities that smart contracts allow.
Smart contracts are an important piece of decentralized applications which we will talk a little more about in the next section.
Decentralized Applications
The autonomous nature of smart contracts has allowed innovators to build entirely self sufficient applications on distributed ledgers. Some of the most notable applications that have helped define decentralized finance have been built using smart contracts. Notable Example are decentralized exchanges (like uniswap, dy/dx, and sushiswap), and marketplaces like opensea.
Trust
An advantage of these programs, is that you can verify they are what they are and do what they claim they are doing. This allows for a permission-less autonomous ecosystem between untrusted and anonymous stakeholders.
Scope
When writing smart contracts, functions can be defined as public or private. Public functions can be called by any permission-less party, while private functions can only be called by the smart contract itself. This specifies who can call these functions. It is also possible to set conditional criteria on these permissions. For example, some NFT projects will allow their users access to an exclusive airdrop if the users' wallet has one of the existing NFTs. There are many opportunities to customize the scope logic.
Composability
Composability is the ability to integrate and work with other systems. Since smart contracts deployed on a public ledger are public, they can be accessed and interacted with by other smart contracts. This gives fruit to an ecosystem of contracts that can interact with each other.
Cost and frugal programing
Using a decentralized public ledger requires transaction fees to pay for the network operation. This is also true regarding smart contracts. When you deploy a smart contract to a network you have to pay a one time fee to the network to compensate the allocation of the program on the ledger. This is the primary reason why these contracts are generally short, the larger your program the more expensive it is to deploy.
The other cost is to the users who interact or run the contract. These are similar to traditional network fees, and they reward the node validators for running the programs in the Ethereum Virtual Machine. There is currently criticism around the large transaction fees on the Ethereum network.
What will that look like tomorrow?
The rate of innovation in this space is lightning fast. While smart contracts were originally only supported on the Ethereum network, now there are many networks taking things further. One of these networks is Hedera Hashgraph who publicly announced their Smart Contracts 2.0 Service which will allow their native network advantages to be utilized with smart contracts. This means that they will be able to support significantly more transactions per second than smart contracts on other networks for a fraction of the cost. The supported scalability of these services is very exciting. More information on the new smart contracts can be found here.
Top comments (15)
I have heard that "validating" smart contracts is not cheap. So while limitless opportunity exists for smart contracts, if they cannot be validated easily and cheaply, their adoption and utility will be constrained. It must be hard to imagine ~500 lines of code from potentially and infinite number of applications being easy to validate and verify.
Thats true. Using a smart contracts costs a transaction fee, and the transaction fees on them can be hefty on the Ethereum network. The composability of these contracts (them calling each other) actually makes the size constriction of these programs quite manageable. You can have lots of small programs making up a larger program.
I was more commenting about involving humans here. So let us posit that a human wants to embed a Smart Contract in some Blockchain. Great. Now let us not care how much Gas or whatever it costs to run. Instead, let us more realistically ask, how much does it cost to evaluate whether this contract is correct or not? For that, apparently, there are few people qualified to do so, hence that in and of itself is currently very expensive. So while in theory all this open source la-dee-da Smart Contracts is great, the reality is, actually using one to transact business will still require an expensive audit before unleashing it. Unless of course one does not care, and we all now how that turns out.
Security is essential, of course. But when it comes to validating the contract behavior, contracts are written in a turing complete language. Additionally, since the contract execution is on a distributed ledger, all the validators on that network (be it PoW or PoS) have to agree on the expected outcome. Since they are deterministic programs, this is a reasonable degree of insurance.
The security advantage of open source software is that there are many eyes on the software, especially if highly utilized. Lots of companies open-source their code to increase security. Granted, this is a new industry, so there are growing pains, but the composability also helps here. For example, a well-known highly regarded Safe Math contract that performs operations that protects against buffer overflows. The standardization of secure ways to do things is happening.
On the other hand, smart contracts have the desired property of immutability. No one can change the functionality on a contract once it is deployed. This is a significant security advantage. One of the pillars in the CIA triad is the integrity of information. Immutability can be leveraged for data integrity guarantees that no other applications in traditional systems allow for.
Furthermore, audits are important, but they are not as difficult as you make out. A well-rounded computer scientist or security researcher can apply methods well known in computer science like fuzzing to perform them. However, it is essential to know that as long as humans are a part of the technical landscape, there is no perfect security.
It is easy to gloss over! I like how you introduce the terms "well-rounded computer scientist". I guess my point is this. Until a system based on and using Smart Contracts comes with a trusted stamp of approval in terms of the contract itself (which in the end, some human conjured up out of nothing, at least for now)... we are left with trusting a bunch of math, and not really sure that is enough. This is not a knock of the theory. It is simply me questioning how this Smart Contract concept can gain wide acceptance when there remain some glaring issues, like provably correct Smart Contracts. Until they come with some badge of assurance themselves, they are just black boxes supposedly correct, but not provably so. They may tickle the correct outputs based on some inputs, but that is not a test I'd trust.
I am biased from my mathematics education, but I think mathematics is the best form of assurance. Public key cryptography is not just some "hocus pocus"; it's incredibly sophisticated. I wrote about it here if you are interested. It's also the technology your bank uses to keep your fiat money safe. The only difference is that they control the keys to you information instead of you. The primary way to prove things in academia is with mathematics. In fact we have built proving systems like Qoc to exactly this. The black boxes are deterministic and provably so. They are a lot more accurate than almost all of our technical infrastructure's current systems.
I am not questioning math. As an engineer I well know the value in speaking math. I have qualms with cryptography and never implied any hocus-pocus? Again, my issue with Smart Contracts (since their inception) has never been their potential value. I have dreamed up many uses for them, none of which are currently needed or practical, but still. I am just commenting that as they become more and more ingrained in systems, those responsible for developing them, will be under heavier and heavier scrutiny, as we cannot simply pass off the old school to the new school, without being sure these contracts are in fact trustable. I think you mistake my concerns for operational aspects as opposed to what they truly are, a question of the ethics, morals and philosophy of how we use them. Finding out too late a contract was responsible for real problems is bound to happen if we have no oversight, and people just blindly trust that some contract is in fact what they believe it is. So it is not a question of the math, but more, does the math implement what it is believed to be correct and sufficient processing to deliver the goods.
Anyway.. thanks for the discussion, all good.
Waylon and David,
I have a lot of thoughts here as well.
I think a lot of the points mentioned here are valid and true as they exist today. Namely, the cost and complexity of smart contracts, potentially out-weighing their use.
I see this as a gap in talent and education. As more and more developers in Web2 transition to Web3 I believe we will learn to write more efficient code that is secure based on attack verticals.
I am a part of a community that trains engineers to write production ready smart contract code that is secure and scalable (Gas efficiency) in response to the exponentially growing demand for engineers in Web3.
I would love to talk more and collaborate with you both and anyone on this thread if you're open to it.
Check it out: optilistic.notion.site/Optilistic-...
I look forward to hearing from you!
Cheers,
Brendan H. Murphy
Optilistic.com
Hey Brendan,
I really love to see this. You are absolutely correct in the gap in talent and education. I am glad to see you doing something about it. Open to chat and collaborate as always. My contact information and DMs are open.
Before posting an article please read about and understand what a smart contract is.
quote>>>>>Smart contracts are part of web3 and are small programs that run autonomously...
Not correct - smart contract are a collection of functions which are residing on a blockchain and are called by Dapps.
These definitions are not mutually excllusive. A Dapp is just a user interface for a smart contract, which does in fact not need a server to run, because it runs on chain, making it autonomus.
It seems your understanding of Dapp-s is not correct either.
Please do read my article on what a Dapp really is -
hackernoon.com/what-a-dapp-really-...
I appreciate your feedback. It is not a mystery that there is a lack of quality education, and granularity in defining terms regarding decentralized protocols. There is also a very high demand for solidity engineers. I'm here to encourage community members, share my years of knowledge as a web3 developer, and computer scientist and help others. I'm not here to debate strangers on granularity or talk tokenomics. I hope you have a lovely day.
regarding - have you deployed a smart contract before? or worked on web3 protocols? Like I said a dapp is just a user interface for a smart contract, it does need a server to run on, unlike a smart contract. It allows an ease of use (not required as you can interact with contracts directly without a dapp) to the users to use the smart contract.
Yes I did deploy multiple smart contracts, and actually are running an independent / owned Ethereum instance. I did also write code serving as Dapp - to read/write on blockchain.
It is very incorrect to claim the Dapp is just the user interface. The max smart contract binary is 25k and most developers limit contract code to save on gas fees. It is the Dapp that makes the functions of the smart contract do something instead of just sitting on the blockchain.
Thank you! Your articles are always so helpful
Some comments have been hidden by the post's author - find out more