fbpx

The problems with Smart Contracts

Listen to this article

Smart Contract:

An automatically executed transaction protocol capable of controlling, documenting, and performing certain actions in accordance with the contract conditions.”

A brief recap of Smart Contracts

Unlike a conventional contract drawn up by a company, bank, or lawyer that is backed by some form of legal obligation, a smart contract requires none of these. Instead of an intermediary enforcer of the contract, the smart contract uses a unique algorithm to monitor transactions between users to ensure each step is completed precisely in accordance with the users contractual agreement.

The smart contract cannot complete a step if the requirements are not properly followed through as smart contracts are tamper-proof. Once they are created, they cannot be changed. This is because smart contracts operate by measure of data, economics, and a unique algorithm generated for every contract that must follow a correct sequence of actions. This is a reliable trustless system that narrows the possibility of fraud down to basically zero.

Smart contracts have tremendous potential, even outside of blockchain and crypto related uses. However, they do have a number of issues to resolve before they will be able to fully realize that potential.

Problems & Limitations

Legal Regulations

With a lack of regulation comes the ability to abuse laws and the opportunity for malicious activity. When something is not regulated, anything that is not explicitly illegal becomes permissible. Smart contracts don’t have any particular legal framework in any region. In addition, they are programmable by anyone and also have freedom of contract. This creates a potentially hazardous environment where extensions of peer-to-peer contracts could become a playground for scammers and cyber attacks.

Furthermore, the majority of smart contracts are coded in Solidity (code language) which is a relatively new coding language, making it difficult for lawyers and officials who lack an understanding of the language to appropriately regulate it.

Fraud

Smart contracts are validated by a consensus of coders / developers before they are permanently launched on the blockchain. Realistically, a majority vote to publish a dangerous smart contract is possible if enough corrupt coders / developers were to team up. There would likely be no way for a casual crypto user to spot the differences between a compromized and a regular smart contract.

Jurisdiction / Location

Smart contracts have the potential to dramatically improve the speed of cross-border transactions. Yet as of right now, there is no way to verify the location and therefore the jurisdiction of a smart contract and the assets involved. This makes them immune to regulation and therefore powerless to exercize legal authority when issues do occur. This creates a difficult scenario when it comes to following local jurisdiction and laws. For smart contracts to evolve and be implemented into the world on a macro level, this must be resolved.

The flip side of Immutability

Immutability means smart contracts are tamper-proof so that the rules and conditions of the contract cannot be changed after deployment. While a very effective safety mechanism that protects the contract itself, any bug or issue that comes up later on becomes insolvable.

Automation concerns

With a completely automated system free of human involvement, the reliability of automatically confirmed information and its validity is a serious concern for many.

Limited use outside blockchain technology

Although many concepts for smart contract uses (outside of blockchain technology) have been proposed, not many have come to fruition. This is because smart contracts have freedom of operation within a blockchain. No other software can match the technological depth of a blockchain, and so to properly operate within another coded framework, the technology will have to be specifically modified.

Another roadblock is that blockchain data isn’t relayed outside of the blockchain, which means there is a severe communication issue between a web3 to web2 contract.

Garbage in – Garbage out

For those who don’t know, this is where faulty or unreliable data input is approved (usually in test runs during the development stage), and as a result the contract doesn’t operate as expected, often causing one party to lose funds or in a locked-in deal they cannot opt out of. They take time, resources, and funds to fully resolve. These elements are all important to the success of a smart contract, so poor input can hurt the success, setback, or completely defeat a team writing contracts.

Privacy

The status and contents of a smart contract in most cases will have to be published on the blockchain ledger. The public transparency of the blockchain – while usually a positive – does not protect the confidentiality of the smart contract and users involved.

Simplicity

Smart contracts are generally quite simple and are usually binary. However, the next unsolved need for smart contracts is the introduction of more complicated actions and ambiguous statements within the contract itself. As of right now, executing a multi party transaction is possible, but incorporating other requirements outside of a simple transaction where developers are struggling to create a viable framework.

A Few Current Solutions

Oracles: These may be the most necessary component when it comes to solving smart contract issues. Oracles provide access to external resources in unique data packages specific to the contract. They essentially are a locked information source only accessible to parties involved in the contract. Oracles are already solving multiple issues for smart contracts:

  • Oracles can relay information safely off-chain and between blockchains and web2 technology.

  • When it comes to dealing with automation concerns, Oracles can source a deeper level of data to break down the contract agreement for parties involved.

  • Resolve Garbage in – Garbage out issues quickly. These issues take some time to resolve, but with the help of Oracles and enhanced data aiding with complex smart contracts, they can be fixed before a bad contract is released, saving resources.

  • Several ways that Oracles are likely to solve privacy-of-transaction concerns have been suggested, but the only successful solutions put into effect has been through Chainlink (a decentralized blockchain oracle network built on Ethereum).

Resolving fraudulent validating: Artificial Randomness is a solution. Randomly selecting coders / developers for the validation process but with several inherently conditions:

  • Only eligible if they have very low to zero contact with the other validators.

  • Implement a score system based off performance / satisfaction of the contracts they verify.

Tackling Immutability: Currently, developers are working on a method of terminating contracts by a majority consensus, and also smart contracts that are terminable at any time.