87e3d177fc1ce06d7ed60b12c40e3eb1 smart contract was introduced in 1994 by Nick Szabo

smart contract was introduced in 1994 by Nick Szabo

 The American Council for Technology and Industry Advisory Council (ACT-IAC) have been developing both a blockchain technology primer and a blockchain playbook. ACT-IAC is a public/private partnership which facilitates collaboration and discussion between government and industry experts. ACT-IAC has developed a blockchain primer document [31], which aims to provide an overview of the technology. A second document, a blockchain playbook [32], provides a set of questions with weights to help organizations in their consideration of the technology. There is no lack of whitepapers and news articles with a title like “Do you need a blockchain?” Two computer scientists at the Eidgenössische Technische Hochschule (ETH) Zürich university in Switzerland wrote a whitepaper titled “Do you need a Blockchain?” [33] which provides the background, properties, and a critical view on several use cases. Although not created by the authors, a website [34] has implemented the flowchart presented in the paper in an interactive form. However, examining the flowchart logic, as well as website code, most paths lead to “no” with only a few leading to “maybe.” This critical view on the technology is one that most organizations should take; organizations should examine whether existing technologies can better solve their problems. 

The Institute of Electrical and Electronics Engineers (IEEE) published in their Spectrum magazine the article “Do you need a blockchain?”[35]. The article emphasizes the utility a blockchain may provide (as an anti-censorship tool), but also discusses the tradeoff that must be made by moving away from a traditional system. Removal of trusted third parties means relying on multiple sources of “unaffiliated participants” acting in coordination, which depending on the type of blockchain platform, may be difficult to govern. The article also discusses that the technology is changing at a rapid pace – so it is difficult to predict where it will end up in a few years’ time. The article includes a flowchart of its own to help the reader decide whether they need a blockchain. Finally, the article ends with the following statement: “But you should also consider the possibility that you don’t need a blockchain at all.” This is pertinent to those who may be desperately looking to include blockchain in their organization’s portfolio. Technology sites are also asking organizations to look closely at the technology and apply it only when necessary. 

Coindesk, a technology website specializing in cryptocurrency and blockchain news, technical matters and editorials, has written the article “Don’t use a blockchain unless you really need one”[36]. The article gives some small examples about how most data today is owned by siloed organizations, and that as users we only supply it to them. It asks what the world would look like if users owned all their data. The article makes the point that the largest benefit of blockchain technology is its decentralization and can be summed up with the article’s most critical point: “Despite some of the hype, blockchains are ‘incredibly inefficient,’ Ravikant said. ‘It's worth paying the cost when you need the decentralization, but it's not when you don't.’” Even software developers are urging organizations to examine the key aspects of the technology and how it could be applied to a problem. One such developer wrote on the website C# Corner the article “Do You Need A Blockchain” [37]. This article touches on the history of blockchain technology and brings to light a primary reason for the use of blockchain technology: “Blockchain brings trust to a transactional system.” NISTIR 8202 BLOCKCHAIN TECHNOLOGY OVERVIEW 44 This publication is available free of charge from: 

https://doi.org/10.6028/NIST.IR.8202 By utilizing a blockchain cryptographic trust can be introduced into a previously no to low trust system. The article goes on to ask several pointed questions (and provides a flowchart) for helping to decide whether a blockchain network would be of benefit. While several sources have been mentioned above for deciding if a blockchain would be applicable, there are many more. Most of the advice surrounding blockchain technology is: investigate it and use it if it is appropriate – not because it is new. 8.1 Additional Blockchain Considerations When deciding whether to utilize a blockchain, one must take into consideration additional factors and determine if these factors limit one’s ability to use a blockchain or a particular type of blockchain: •

 Data Visibility o Permissioned blockchain networks may or may not reveal blockchain data publicly. The data may only be available to those within the blockchain network. Consider scenarios where data may be governed by policy or regulations (such as Personally Identifiable Information (PII) or General Data Protection Regulation (GDPR) regulations). Data such as this may or may not be appropriate to store even within a permissioned blockchain network. o Permissionless blockchain networks can allow anyone to inspect and contribute to the blockchain. The data is generally public. This leads to several questions that must be considered. Does the data for the application need to be available to everyone? Is there any harm to having public data? • Full transactional history – Some blockchain networks provide a full public history of a digital asset – from creation, to every transaction it is included in. This feature may be beneficial for some solutions, and not beneficial for others. 

• Fake Data Input – Since multiple users are contributing to a blockchain, some could submit false data, mimicking data from valid sources (such as sensor data). It is difficult to automate the verification of data that enters a blockchain network. Smart contract implementations may provide additional checks to help validate data where possible. • Tamper evident and tamper resistant data – Many applications follow the “CRUD” (create, read, update, delete) functions for data. With a blockchain, there is only “CR” (create, read). 

There are methods that can be employed to “deprecate” older data if a newer version is found, but there is no removal process for the original data. By using new transactions to amend and update previous transactions, data can be updated while providing a full history. However, even if a new transaction marked an older transaction as “deleted” – the data would still be present in the blockchain data, even if it is not shown within an application processing the data. • Transactions Per Second – Transaction processing speed is highly dependent on the consensus model used. Currently transactions on many permissionless blockchain networks are not executed at the same pace as other information technology solutions due to a slow publication time for blocks (usually in terms of seconds, but sometimes minutes). Thus, some slowdown in blockchain dependent applications may occur white

waiting for data to be posted. One must ask if their application can handle relatively slow transaction processing? • Compliance – The use of blockchain technology does not exclude a system from following any applicable laws and regulations. For example, there are many compliance considerations with regards to legislation and policies tied to PII or GDPR that identify that certain information should not be placed on the blockchain. In addition, certain countries may limit the type of data that can be transferred across its geographic boundary. In other instances, certain legislation may dictate that the “first write” of financial transactions must be written to a node which is present within their borders. In any of these cases, a public, permissionless chain may be less appropriate, with a permissioned or hybrid approach required to satisfy regulatory needs. An additional example of laws and regulations are for any blockchain network which manages federal records. 

Federal records are subject to many laws and regulations.11 Federal agencies themselves must follow specific federal guidelines when utilizing blockchain technology.12 • Permissions – For permissioned blockchain networks, there are considerations around the permissions themselves o Granularity – do the permissions within the system allow for enough granularity for specific roles that users may need (in a manner like Role-Based Access Control methods) to perform actions within the system  Permissioned blockchain networks allow for more traditional roles such as administrator, user, validator, auditor, etc. o Administration – who can administer permissions?

 Once permissions are administered to a user, can they easily be revoked? • Node Diversity – A blockchain network is only as strong as the aggregate of all the existing nodes participating in the network. If all the nodes share similar hardware, software, geographic location, and messaging schema then there exists a certain amount of risk associated with the possibility of undiscovered security vulnerabilities. This risk is mitigated through the decentralization of the network of heterogeneous devices, which may be defined as “the non-shared characteristics between any one node and the generalized set” 



6. Smart Contracts in Blockchain


6.1 Introduction to Smart Contracts

The term smart contract was introduced in 1994 by Nick Szabo.

Definition

A smart contract is:

“A computerized transaction protocol that executes the terms of a contract.”

Objectives

  • Enforce contractual conditions automatically

  • Minimize:

    • Fraud (malicious exceptions)

    • Errors (accidental exceptions)

  • Reduce reliance on trusted intermediaries


6.2 Concept and Working

Smart contracts extend blockchain functionality by combining:

  • Code (functions)

  • Data (state)

Deployment

  • Deployed through cryptographically signed transactions

  • Stored and executed on blockchain networks such as:

    • Ethereum

    • Hyperledger Fabric


Execution Process

  1. User sends transaction with input data

  2. Smart contract function is triggered

  3. Code executes across blockchain nodes

  4. All nodes must produce the same result

  5. Output is recorded on the blockchain


6.3 Features of Smart Contracts

6.3.1 Tamper Resistance

  • Stored on blockchain → cannot be altered

  • Ensures trust and integrity


6.3.2 Automation

  • Automatically executes when conditions are met

  • Eliminates need for intermediaries


6.3.3 Transparency

  • Code and results are visible to network participants


6.3.4 Functional Capabilities

Smart contracts can:

  • Perform calculations

  • Store data

  • Expose system state

  • Transfer funds automatically

✔ Not limited to financial use


6.4 Applications of Smart Contracts

  • Financial transactions

  • Supply chain management

  • Voting systems

  • Random number generation (e.g., Ethereum-based solutions)

  • Business process automation


6.5 Multi-Party Transactions

Smart contracts support multi-party agreements.

Benefits

  • Improved transparency

  • Reduced reconciliation costs

  • Faster transaction processing

  • Better decision-making through shared data


6.6 Deterministic Nature

Smart contracts must be deterministic:

  • Same input → same output

  • All nodes must agree on results


Restriction

  • Cannot directly access external data

  • Must rely only on:

    • Input parameters

    • Internal blockchain data


6.7 Oracle Concept

When smart contracts require external data, they use an Oracle.

Oracle Role

  • Provides external data (e.g., weather, prices)

  • Acts as a bridge between blockchain and real world


6.8 Execution Models

6.8.1 Permissionless Blockchains

Example: Ethereum

  • All nodes execute smart contracts

  • Users must pay execution fees (gas)

Gas Mechanism

  • Limits execution time

  • Prevents:

    • Infinite loops

    • Denial-of-service attacks


6.8.2 Permissioned Blockchains

Example: Hyperledger Fabric

  • Known participants

  • May not require execution fees

  • Some nodes:

    • Execute contracts

    • Others validate results


6.9 Security and Resource Control

  • Execution limits prevent resource abuse

  • Ensures fair usage of network resources

  • Protects against malicious smart contracts


6.10 Limitations

  • Cannot directly access external data

  • Bugs in code can cause vulnerabilities

  • Not all blockchains support smart contracts


6.11 Conclusion

Smart contracts are a powerful extension of blockchain technology that enable:

  • Automation

  • Transparency

  • Trust without intermediaries

However, they require:

  • Careful design

  • Secure coding

  • Reliable external data sources

Post a Comment

0 Comments