Recommended: As smart contracts get smarter, the rules of development will change | VentureBeat
(venturebeat.com)
If 2017 was the year of Bitcoin, 2018 will be the year of the smart contract.Smart contracts — the self-executing coded contracts running on blockchain networks — enable decentralized apps (dApps) and the brand new economic models we are see emerging on blockchains.
While it’s difficult to gauge exactly how many smart contracts are already out there, State of the dApps lists more than 1,000 built on Ethereum, the most popular blockchain for dApp development.If, as many believe, blockchain will eventually enable a decentralized version of the internet, a huge number of decentralized applications will need to be built — along with their associated smart contracts.
The CryptoKitties smart contract may be working the Ethereum network hardest right now, but with a diverse range of industry use cases, we’ll see smart contracts that address all kinds of commercial situations. Some may be simple and straightforward, but, as blockchain adoption accelerates amongst enterprises, others will be more elaborate to address complex business needs.
Smart contracts exist to automatically perform validation steps and encode the conditions of a physical contract. They need to be safe, secure, transparent, and capable of automating administrative activity and eliminating human error.There’s a lot of excitement about the potential for smart contracts to transform the way we work today. However, we’re not there yet.
To understand where we are, it’s worth considering the smart contract at the heart of one of the biggest ICOs of 2017. Bancor, which famously raised $153 million in just three hours, has also infamously been referred to as a market maker written in “40 lines of code.” To be clear, Bancor’s full application stack runs closer to runs closer to 60,000 lines of code — but its smart contract clocks in at 40.
What can you accomplish in 40 lines of code? Not much — which is fine, because Bancor’s smart contract was designed to automate a relatively simple business use case: governing the financial terms of trading one token with another in a P2P environment.
Solving more complex use cases going forward will mean constructing more complex smart contracts.Blockchain projects like Chronicled and Qtum already support access to trusted off-chain data sources (“oracles”) and Internet of Things (IoT) sensors to allow off-chain events to trigger clauses in smart contracts. And future smart contracts may need to add code that enables greater privacy for the contents of the contract considering the radical transparency blockchain offers.
Blockchain’s promise of immutability may also be up for grabs: Businesses wanting to be able to reverse transactions will need to this complex capability into their smart contracts.
Now, instead of 40 lines of code, we could be talking about tens of thousands. And each additional line of code carries with it an additional portion of risk: that between business case and code, some meaning has been lost; that the smart contract will not execute as the developer intends or as the business stakeholder demands; and that money will be irretrievably lost. The more complex the use case, the greater the volume of code. The greater the volume of code, the greater the risk of failure.
Greater volumes of code also mean greater processing power requirements — and a corresponding reduction in speed of execution. This is already an area of concern for the enterprise market, which expects high-volume and high-speed processing power as a basic requirement, not a bonus feature. Unlike the cloud, blockchain isn’t able to simply expand and contract to meet capacity demands.
The more load the blockchain has to handle, the slower it performs. (Although, there are a number of new protocols under development that hope to crush that limitation.)
One way of heading off mistakes is for smart contract developers to work more closely with legal experts. While developers might prefer the “if this, then that” logic of computer code, this sort of collaboration is the only way to build smart contracts that deal with nuanced and subjective areas of the commercial world.Smart contracts will also need to use big data flows from IoT devices.
This convergence has already begun, most notably with IBM and Maersk joining upto create a blockchain-enabled global shipping platform. Current smart contracts cannot handle the large volumes of data from multiple different “oracles” that is needed to automatically execute complex agreements. Instead, IBM and Maersk, and anyone else wanting to exploit the convergence of IoT and blockchain, will need to build these new, more complex smart contracts from scratch.
Finally, in addition to legal expertise and big data, artificial intelligence and machine learning will be crucial ingredients in future smart contracts. The sooner AI is introduced, the sooner computers will be able to learn what the most important data is and where the flaws in a smart contract exist. Eventually, AI could go beyond eliminating the manual human verification processes and take over the negotiation and development stages of smart contracts too.
While a number of companies are already exploring the convergence of blockchain and AI, AI-as-a-Service solutions like those from IOTA, Ocean Protocol, and SingularityNet may have the edge. By eliminating the need to invest in home-grown AI technology, which is both expensive and complex, these providers offer “AI training” services to any blockchain company.
Smart contract development is going to hit some breakers this year because of the small developer pool available with the right skills.You won’t find many programmers proficient in Solidity, Ethereum’s contract-oriented programming language. Even the most well-known and well-funded blockchain projects are struggling to recruit.
Simplicity is gradually being introduced as a language for Bitcoin-based smart contracts, but it will inevitably take time to bed in. Of course, there are alternatives. NEO smart contracts support languages like C# and Java, with Python support planned for the future.
With this range of languages, standardization of smart contract protocols will be important if they are to proliferate and become smarter. Standardization will also support the progress of developers who are currently working in the “walled garden” of one chain but will need to work in a multi-chain environment more and more.
While that’s something the industry as a whole can work towards, for now, individual developers should try to keep things simple, taking the time to understand what does and doesn’t belong in the smart contract.The demand for decentralized apps is only going to grow over the coming year. And smart contracts will need to get smarter quickly to support those apps.
I expect 2018 to be the year we see a move towards setting the standards and guidelines for the development of these contracts, including who developers work with to develop the application logic, what language they code in, and how they design their code for an environment where mistakes are extremely costly. This is no longer the era of “agile” development and failing forward; foresight and accuracy are key.
Craig Sproule is CEO of Crowd Machine, maker of a decentralized app building and execution network.
More from VentureBeat here: https://venturebeat.com/2018/02/18/as-smart-contracts-get-smarter-the-rules-of-development-will-chan...
While it’s difficult to gauge exactly how many smart contracts are already out there, State of the dApps lists more than 1,000 built on Ethereum, the most popular blockchain for dApp development.If, as many believe, blockchain will eventually enable a decentralized version of the internet, a huge number of decentralized applications will need to be built — along with their associated smart contracts.
The CryptoKitties smart contract may be working the Ethereum network hardest right now, but with a diverse range of industry use cases, we’ll see smart contracts that address all kinds of commercial situations. Some may be simple and straightforward, but, as blockchain adoption accelerates amongst enterprises, others will be more elaborate to address complex business needs.
The state of smart contracts
Smart contracts exist to automatically perform validation steps and encode the conditions of a physical contract. They need to be safe, secure, transparent, and capable of automating administrative activity and eliminating human error.There’s a lot of excitement about the potential for smart contracts to transform the way we work today. However, we’re not there yet.
To understand where we are, it’s worth considering the smart contract at the heart of one of the biggest ICOs of 2017. Bancor, which famously raised $153 million in just three hours, has also infamously been referred to as a market maker written in “40 lines of code.” To be clear, Bancor’s full application stack runs closer to runs closer to 60,000 lines of code — but its smart contract clocks in at 40.
What can you accomplish in 40 lines of code? Not much — which is fine, because Bancor’s smart contract was designed to automate a relatively simple business use case: governing the financial terms of trading one token with another in a P2P environment.
Solving more complex use cases going forward will mean constructing more complex smart contracts.Blockchain projects like Chronicled and Qtum already support access to trusted off-chain data sources (“oracles”) and Internet of Things (IoT) sensors to allow off-chain events to trigger clauses in smart contracts. And future smart contracts may need to add code that enables greater privacy for the contents of the contract considering the radical transparency blockchain offers.
Blockchain’s promise of immutability may also be up for grabs: Businesses wanting to be able to reverse transactions will need to this complex capability into their smart contracts.
Now, instead of 40 lines of code, we could be talking about tens of thousands. And each additional line of code carries with it an additional portion of risk: that between business case and code, some meaning has been lost; that the smart contract will not execute as the developer intends or as the business stakeholder demands; and that money will be irretrievably lost. The more complex the use case, the greater the volume of code. The greater the volume of code, the greater the risk of failure.
Greater volumes of code also mean greater processing power requirements — and a corresponding reduction in speed of execution. This is already an area of concern for the enterprise market, which expects high-volume and high-speed processing power as a basic requirement, not a bonus feature. Unlike the cloud, blockchain isn’t able to simply expand and contract to meet capacity demands.
The more load the blockchain has to handle, the slower it performs. (Although, there are a number of new protocols under development that hope to crush that limitation.)
Smarter smart contracts
One way of heading off mistakes is for smart contract developers to work more closely with legal experts. While developers might prefer the “if this, then that” logic of computer code, this sort of collaboration is the only way to build smart contracts that deal with nuanced and subjective areas of the commercial world.Smart contracts will also need to use big data flows from IoT devices.
This convergence has already begun, most notably with IBM and Maersk joining upto create a blockchain-enabled global shipping platform. Current smart contracts cannot handle the large volumes of data from multiple different “oracles” that is needed to automatically execute complex agreements. Instead, IBM and Maersk, and anyone else wanting to exploit the convergence of IoT and blockchain, will need to build these new, more complex smart contracts from scratch.
Finally, in addition to legal expertise and big data, artificial intelligence and machine learning will be crucial ingredients in future smart contracts. The sooner AI is introduced, the sooner computers will be able to learn what the most important data is and where the flaws in a smart contract exist. Eventually, AI could go beyond eliminating the manual human verification processes and take over the negotiation and development stages of smart contracts too.
While a number of companies are already exploring the convergence of blockchain and AI, AI-as-a-Service solutions like those from IOTA, Ocean Protocol, and SingularityNet may have the edge. By eliminating the need to invest in home-grown AI technology, which is both expensive and complex, these providers offer “AI training” services to any blockchain company.
The developer question
Smart contract development is going to hit some breakers this year because of the small developer pool available with the right skills.You won’t find many programmers proficient in Solidity, Ethereum’s contract-oriented programming language. Even the most well-known and well-funded blockchain projects are struggling to recruit.
Simplicity is gradually being introduced as a language for Bitcoin-based smart contracts, but it will inevitably take time to bed in. Of course, there are alternatives. NEO smart contracts support languages like C# and Java, with Python support planned for the future.
With this range of languages, standardization of smart contract protocols will be important if they are to proliferate and become smarter. Standardization will also support the progress of developers who are currently working in the “walled garden” of one chain but will need to work in a multi-chain environment more and more.
While that’s something the industry as a whole can work towards, for now, individual developers should try to keep things simple, taking the time to understand what does and doesn’t belong in the smart contract.The demand for decentralized apps is only going to grow over the coming year. And smart contracts will need to get smarter quickly to support those apps.
I expect 2018 to be the year we see a move towards setting the standards and guidelines for the development of these contracts, including who developers work with to develop the application logic, what language they code in, and how they design their code for an environment where mistakes are extremely costly. This is no longer the era of “agile” development and failing forward; foresight and accuracy are key.
Craig Sproule is CEO of Crowd Machine, maker of a decentralized app building and execution network.
More from VentureBeat here: https://venturebeat.com/2018/02/18/as-smart-contracts-get-smarter-the-rules-of-development-will-chan...
-
- 1
Francisco Gimeno - BC Analyst Nice to read this, no more easy smart contracts in this 2018, but smart contracts which fall under standard and guidelines focusing on accuracy and key, in order to prepare for the development of Dapps to solve real use cases with Blockchain.