Blockchain systems can be subdivided into two broad categories:
- Turing Complete
- Non-Turing Complete.
This means the design of the system’s contract language is either Turing Complete or it is not. The largest of each of these two categories is Bitcoin as a non-Turing Complete contract language and Ethereum as a Turing-Complete contract language. The reason this is important is because it describes the inherent design goal of language.
Turing-Complete languages allow for theoretically any computation to be completed, whereas non-Turing Complete languages have a more limited instruction set that specifically limit the actions available in that language.
The reason for adding these limitations to the language is to limit the functionality and therefore potential complexity of code put onto the blockchain’s public ledger and executed distributedly.
Non-Turing Complete contract languages are easier to analyze and predict runtime behavior, results, and potential faults.
Additionally, there are blockchain/distributed ledger frameworks such as Hyperledger Fabric which do not provide a specific public blockchain for use, but instead provide tools for developing customizable blockchain/distributed ledger applications or implementations modularly.
During roughly the same time as the growth of blockchain, the increased proliferation of IoT devices has motivated the need for transactional integrity due to the transition of IoT devices from just being smart-sensors to being active participants that impact their environment via communication, decision making, and physical actuation. These abilities require transactional integrity to provide auditing of actions made by potentially untrusted networked 3rd party IoT devices. The demand for transactional integrity in IoT devices that simultaneously leverage blockchain features (such as decentralization, cryptographic security, and immutability) has motivated research on creating transactive IoT blockchain applications.
This requirement becomes even more important when integrating IoT blockchain applications (ITBAs). The IoT component of ITBAs add other requirements atop traditional blockchain applications due to their interactions with the physical environment and increased privacy concerns, e.g., thus preventing leakage of personal data, such as energy usage that would reveal a user’s activity patterns in their home.
Moreover, ITBAs may not only communicate over the blockchain, but may also use off-blockchain communications via TCP/IP or other networking protocols for the following reasons:
• There are interactions with the physical environment that might require communication with sensors and/or actuators. For example, a user’s smart-meter might communicate wirelessly with their smart-car’s battery to activate charging based on current energy production/cost considerations.
• The distributed ledger (which makes an immutable record of transactions in blockchain) is public, so it is common to only include information within transactions that can safely be stored publicly. In particular, if some or all data from a transaction must be kept secret for privacy or any other reasons the transaction can, instead, contain the meta-data and a cryptographic hash of the secret data. Private information must, therefore, be communicated off-blockchain while still preserving integrity by storing metadata and hash information on the blockchain ledger.
• Management tasks such as: updates, monitoring, calibration, debugging, or auditing may require off-blockchain communication (with possible on-blockchain components for logging). Currently, these management tasks are done manually in conventional blockchain ecosystems. Similar to the need for a systematic means of deploying apps in a blockchain network, there is a need to systematically configure the network topology between all components of ITBAs.
[ad_2]
This article has been published from the source link without modifications to the text. Only the headline has been changed.
