CINXE.COM

<!DOCTYPE html> <html class="writer-html5" lang="en" data-content_root="../"> <head> <meta charset="utf-8" /><meta name="viewport" content="width=device-width, initial-scale=1" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Smart Contracts and Chaincode — Hyperledger Fabric Docs main documentation</title> <link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=fa44fd50" /> <link rel="stylesheet" type="text/css" href="../_static/css/theme.css?v=e59714d7" /> <link rel="stylesheet" type="text/css" href="../_static/css/custom.css?v=c3038dac" /> <script src="../_static/jquery.js?v=5d32c60e"></script> <script src="../_static/_sphinx_javascript_frameworks_compat.js?v=2cd50e6c"></script> <script src="../_static/documentation_options.js?v=a8da1a53"></script> <script src="../_static/doctools.js?v=9bcbadda"></script> <script src="../_static/sphinx_highlight.js?v=dc90522c"></script> <script src="../_static/js/theme.js"></script> <link rel="index" title="Index" href="../genindex.html" /> <link rel="search" title="Search" href="../search.html" /> <link rel="next" title="Fabric chaincode lifecycle" href="../chaincode_lifecycle.html" /> <link rel="prev" title="The Ordering Service" href="../orderer/ordering_service.html" /> <script async type="text/javascript" src="/_/static/javascript/readthedocs-addons.js"></script><meta name="readthedocs-project-slug" content="hyperledger-fabric" /><meta name="readthedocs-version-slug" content="latest" /><meta name="readthedocs-resolver-filename" content="/smartcontract/smartcontract.html" /><meta name="readthedocs-http-status" content="200" /></head> <body class="wy-body-for-nav"> <div class="wy-grid-for-nav"> <nav data-toggle="wy-nav-shift" class="wy-nav-side"> <div class="wy-side-scroll"> <div class="wy-side-nav-search" > <a href="../index.html" class="icon icon-home"> Hyperledger Fabric Docs </a> <div role="search"> <form id="rtd-search-form" class="wy-form" action="../search.html" method="get"> <input type="text" name="q" placeholder="Search docs" aria-label="Search docs" /> <input type="hidden" name="check_keywords" value="yes" /> <input type="hidden" name="area" value="default" /> </form> </div> <img style="background-color: #fff; height: unset; width: unset;" alt="Hyperledger Fabric" src=../_images/hyperledger_fabric_logo_color.png /> <a href="https://github.com/hyperledger/fabric"><img style="padding: 0px; margin: auto auto auto auto;" alt="GitHub" src="../_static/images/github_button.png"/></a>  <a href="https://stackoverflow.com/questions/tagged/hyperledger-fabric"><img style="padding: 0px; margin: auto auto auto auto;" alt="StackOverflow" src="../_static/images/stackoverflow_button.png"/></a>  <a href="https://discord.com/invite/hyperledger"><img style="padding: 0px; margin: auto auto auto auto;" alt="Discord" src="../_static/images/discord_button.png"/></a>  <a href="https://www.youtube.com/playlist?list=PL0MZ85B_96CH7wvtrRzV7SvtRY0sI0DEg"><img style="padding: 0px; margin: auto auto auto auto;" alt="Youtube Channel" src="../_static/images/youtube_button.png"/></a> </div><div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="Navigation menu"> <ul class="current"> <li class="toctree-l1"><a class="reference internal" href="../whatis.html">Introduction</a></li> <li class="toctree-l1"><a class="reference internal" href="../whatsnew.html">What’s new in Hyperledger Fabric</a></li> <li class="toctree-l1"><a class="reference internal" href="../whatsnew.html#release-notes">Release notes</a></li> <li class="toctree-l1 current"><a class="reference internal" href="../key_concepts.html">Key Concepts</a><ul class="current"> <li class="toctree-l2"><a class="reference internal" href="../blockchain.html">Introduction</a></li> <li class="toctree-l2"><a class="reference internal" href="../fabric_model.html">Hyperledger Fabric Model</a></li> <li class="toctree-l2"><a class="reference internal" href="../network/network.html">How Fabric networks are structured</a></li> <li class="toctree-l2"><a class="reference internal" href="../identity/identity.html">Identity</a></li> <li class="toctree-l2"><a class="reference internal" href="../membership/membership.html">Membership Service Provider (MSP)</a></li> <li class="toctree-l2"><a class="reference internal" href="../policies/policies.html">Policies</a></li> <li class="toctree-l2"><a class="reference internal" href="../peers/peers.html">Peers</a></li> <li class="toctree-l2"><a class="reference internal" href="../ledger/ledger.html">Ledger</a></li> <li class="toctree-l2"><a class="reference internal" href="../orderer/ordering_service.html">The Ordering Service</a></li> <li class="toctree-l2 current"><a class="current reference internal" href="#">Smart Contracts and Chaincode</a><ul> <li class="toctree-l3"><a class="reference internal" href="#smart-contract">Smart contract</a></li> <li class="toctree-l3"><a class="reference internal" href="#terminology">Terminology</a></li> <li class="toctree-l3"><a class="reference internal" href="#ledger">Ledger</a></li> <li class="toctree-l3"><a class="reference internal" href="#development">Development</a></li> <li class="toctree-l3"><a class="reference internal" href="#endorsement">Endorsement</a></li> <li class="toctree-l3"><a class="reference internal" href="#valid-transactions">Valid transactions</a></li> <li class="toctree-l3"><a class="reference internal" href="#channels">Channels</a></li> <li class="toctree-l3"><a class="reference internal" href="#intercommunication">Intercommunication</a></li> <li class="toctree-l3"><a class="reference internal" href="#system-chaincode">System chaincode</a></li> </ul> </li> <li class="toctree-l2"><a class="reference internal" href="../chaincode_lifecycle.html">Fabric chaincode lifecycle</a></li> <li class="toctree-l2"><a class="reference internal" href="../private-data/private-data.html">Private data</a></li> <li class="toctree-l2"><a class="reference internal" href="../capabilities_concept.html">Channel capabilities</a></li> <li class="toctree-l2"><a class="reference internal" href="../security_model.html">Security Model</a></li> <li class="toctree-l2"><a class="reference internal" href="../usecases.html">Use Cases</a></li> </ul> </li> <li class="toctree-l1"><a class="reference internal" href="../getting_started.html">Getting Started - Install</a></li> <li class="toctree-l1"><a class="reference internal" href="../getting_started_run_fabric.html">Getting Started - Run Fabric</a></li> <li class="toctree-l1"><a class="reference internal" href="../tutorials.html">Tutorials</a></li> <li class="toctree-l1"><a class="reference internal" href="../deployment_guide_overview.html">Deploying a production network</a></li> <li class="toctree-l1"><a class="reference internal" href="../ops_guide.html">Operations Guides</a></li> <li class="toctree-l1"><a class="reference internal" href="../upgrade.html">Upgrading to the latest release</a></li> <li class="toctree-l1"><a class="reference internal" href="../command_ref.html">Commands Reference</a></li> <li class="toctree-l1"><a class="reference internal" href="../architecture.html">Architecture Reference</a></li> <li class="toctree-l1"><a class="reference internal" href="../Fabric-FAQ.html">Frequently Asked Questions</a></li> <li class="toctree-l1"><a class="reference internal" href="../CONTRIBUTING.html">Contributions Welcome!</a></li> <li class="toctree-l1"><a class="reference internal" href="../glossary.html">Glossary</a></li> <li class="toctree-l1"><a class="reference internal" href="../releases.html">Releases</a></li> <li class="toctree-l1"><a class="reference internal" href="../questions.html">Still Have Questions?</a></li> <li class="toctree-l1"><a class="reference internal" href="../status.html">Status</a></li> </ul> </div> </div> </nav> <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap"><nav class="wy-nav-top" aria-label="Mobile navigation menu" > <a href="../index.html">Hyperledger Fabric Docs</a> </nav> <div class="wy-nav-content"> <div class="rst-content"> <div role="navigation" aria-label="Page navigation"> <ul class="wy-breadcrumbs"> <li><a href="../index.html" class="icon icon-home" aria-label="Home"></a></li> <li class="breadcrumb-item"><a href="../key_concepts.html">Key Concepts</a></li> <li class="breadcrumb-item active">Smart Contracts and Chaincode</li> <li class="wy-breadcrumbs-aside"> <a href="../_sources/smartcontract/smartcontract.md.txt" rel="nofollow"> View page source</a> </li> </ul> <hr/> </div> <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article"> <div itemprop="articleBody"> <section id="smart-contracts-and-chaincode"> <h1>Smart Contracts and Chaincode<a class="headerlink" href="#smart-contracts-and-chaincode" title="Link to this heading">¶</a></h1> Audience: Architects, application and smart contract developers, administrators From an application developer’s perspective, a smart contract, together with the <a class="reference external" href="../ledger/ledger.html">ledger</a>, form the heart of a Hyperledger Fabric blockchain system. Whereas a ledger holds facts about the current and historical state of a set of business objects, a smart contract defines the executable logic that generates new facts that are added to the ledger. A chaincode is typically used by administrators to group related smart contracts for deployment, but can also be used for low level system programming of Fabric. In this topic, we’ll focus on why both smart contracts and chaincode exist, and how and when to use them. In this topic, we’ll cover: <ul class="simple"> <li><a class="reference external" href="#smart-contracts-and-chaincode">Smart Contracts and Chaincode</a> <ul> <li><a class="reference external" href="#smart-contract">Smart contract</a></li> <li><a class="reference external" href="#terminology">Terminology</a></li> <li><a class="reference external" href="#ledger">Ledger</a></li> <li><a class="reference external" href="#development">Development</a></li> <li><a class="reference external" href="#endorsement">Endorsement</a></li> <li><a class="reference external" href="#valid-transactions">Valid transactions</a></li> <li><a class="reference external" href="#channels">Channels</a></li> <li><a class="reference external" href="#intercommunication">Intercommunication</a></li> <li><a class="reference external" href="#system-chaincode">System chaincode</a></li> </ul> </li> </ul> <section id="smart-contract"> <h2>Smart contract<a class="headerlink" href="#smart-contract" title="Link to this heading">¶</a></h2> Before businesses can transact with each other, they must define a common set of contracts covering common terms, data, rules, concept definitions, and processes. Taken together, these contracts lay out the business model that govern all of the interactions between transacting parties. <img alt="smart.diagram1" src="../_images/smartcontract.diagram.01.png" /> A smart contract defines the rules between different organizations in executable code. Applications invoke a smart contract to generate transactions that are recorded on the ledger. Using a blockchain network, we can turn these contracts into executable programs – known in the industry as smart contracts – to open up a wide variety of new possibilities. That’s because a smart contract can implement the governance rules for any type of business object, so that they can be automatically enforced when the smart contract is executed. For example, a smart contract might ensure that a new car delivery is made within a specified timeframe, or that funds are released according to prearranged terms, improving the flow of goods or capital respectively. Most importantly however, the execution of a smart contract is much more efficient than a manual human business process. In the <a class="reference external" href="#smart-contract">diagram above</a>, we can see how two organizations, <code class="docutils literal notranslate">ORG1</code> and <code class="docutils literal notranslate">ORG2</code> have defined a <code class="docutils literal notranslate">car</code> smart contract to <code class="docutils literal notranslate">query</code>, <code class="docutils literal notranslate">transfer</code> and <code class="docutils literal notranslate">update</code> cars. Applications from these organizations invoke this smart contract to perform an agreed step in a business process, for example to transfer ownership of a specific car from <code class="docutils literal notranslate">ORG1</code> to <code class="docutils literal notranslate">ORG2</code>. </section> <section id="terminology"> <h2>Terminology<a class="headerlink" href="#terminology" title="Link to this heading">¶</a></h2> Hyperledger Fabric users often use the terms smart contract and chaincode interchangeably. In general, a smart contract defines the transaction logic that controls the lifecycle of a business object contained in the world state. It is then packaged into a chaincode which is then deployed to a blockchain network. Think of smart contracts as governing transactions, whereas chaincode governs how smart contracts are packaged for deployment. <img alt="smart.diagram2" src="../_images/smartcontract.diagram.02.png" /> A smart contract is defined within a chaincode. Multiple smart contracts can be defined within the same chaincode. When a chaincode is deployed, all smart contracts within it are made available to applications. In the diagram, we can see a <code class="docutils literal notranslate">vehicle</code> chaincode that contains three smart contracts: <code class="docutils literal notranslate">cars</code>, <code class="docutils literal notranslate">boats</code> and <code class="docutils literal notranslate">trucks</code>. We can also see an <code class="docutils literal notranslate">insurance</code> chaincode that contains four smart contracts: <code class="docutils literal notranslate">policy</code>, <code class="docutils literal notranslate">liability</code>, <code class="docutils literal notranslate">syndication</code> and <code class="docutils literal notranslate">securitization</code>. In both cases these contracts cover key aspects of the business process relating to vehicles and insurance. In this topic, we will use the <code class="docutils literal notranslate">car</code> contract as an example. We can see that a smart contract is a domain specific program which relates to specific business processes, whereas a chaincode is a technical container of a group of related smart contracts. </section> <section id="ledger"> <h2>Ledger<a class="headerlink" href="#ledger" title="Link to this heading">¶</a></h2> At the simplest level, a blockchain immutably records transactions which update states in a ledger. A smart contract programmatically accesses two distinct pieces of the ledger – a blockchain, which immutably records the history of all transactions, and a world state that holds a cache of the current value of these states, as it’s the current value of an object that is usually required. Smart contracts primarily put, get and delete states in the world state, and can also query the immutable blockchain record of transactions. <ul class="simple"> <li>A get typically represents a query to retrieve information about the current state of a business object.</li> <li>A put typically creates a new business object or modifies an existing one in the ledger world state.</li> <li>A delete typically represents the removal of a business object from the current state of the ledger, but not its history.</li> </ul> Smart contracts have many <a class="reference external" href="../chaincode4ade.html#fabric-contract-api">APIs</a> available to them. Critically, in all cases, whether transactions create, read, update or delete business objects in the world state, the blockchain contains an <a class="reference external" href="../ledger/ledger.html">immutable record</a> of these changes. </section> <section id="development"> <h2>Development<a class="headerlink" href="#development" title="Link to this heading">¶</a></h2> Smart contracts are the focus of application development, and as we’ve seen, one or more smart contracts can be defined within a single chaincode. Deploying a chaincode to a network makes all its smart contracts available to the organizations in that network. It means that only administrators need to worry about chaincode; everyone else can think in terms of smart contracts. At the heart of a smart contract is a set of <code class="docutils literal notranslate">transaction</code> definitions. For example, look at assetTransfer.js <a class="reference external" href="https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-basic/chaincode-javascript/lib/assetTransfer.js#L67">here</a>, where you can see a smart contract transaction that creates a new asset: <div class="highlight-javascript notranslate"><div class="highlight"><pre> async CreateAsset(ctx, id, color, size, owner, appraisedValue) { const asset = { ID: id, Color: color, Size: size, Owner: owner, AppraisedValue: appraisedValue, }; return ctx.stub.putState(id, Buffer.from(JSON.stringify(asset))); } </pre></div> </div> You can learn more about the Basic smart contract in the <a class="reference external" href="../write_first_app.html">Running a Fabric Application</a> tutorial. A smart contract can describe an almost infinite array of business use cases relating to immutability of data in multi-organizational decision making. The job of a smart contract developer is to take an existing business process that might govern financial prices or delivery conditions, and express it as a smart contract in a programming language such as JavaScript, Go, or Java. The legal and technical skills required to convert centuries of legal language into programming language is increasingly practiced by smart contract auditors. You can learn about how to design and develop a smart contract in the <a class="reference external" href="../developapps/developing_applications.html">Developing applications topic</a>. </section> <section id="endorsement"> <h2>Endorsement<a class="headerlink" href="#endorsement" title="Link to this heading">¶</a></h2> Associated with every chaincode is an endorsement policy that applies to all of the smart contracts defined within it. An endorsement policy is very important; it indicates which organizations in a blockchain network must sign a transaction generated by a given smart contract in order for that transaction to be declared valid. <img alt="smart.diagram3" src="../_images/smartcontract.diagram.03.png" /> Every smart contract has an endorsement policy associated with it. This endorsement policy identifies which organizations must approve transactions generated by the smart contract before those transactions can be identified as valid. An example endorsement policy might define that three of the four organizations participating in a blockchain network must sign a transaction before it is considered valid. All transactions, whether valid or invalid are added to a distributed ledger, but only valid transactions update the world state. If an endorsement policy specifies that more than one organization must sign a transaction, then the smart contract must be executed by a sufficient set of organizations in order for a valid transaction to be generated. In the example <a class="reference external" href="#endorsement">above</a>, a smart contract transaction to <code class="docutils literal notranslate">transfer</code> a car would need to be executed and signed by both <code class="docutils literal notranslate">ORG1</code> and <code class="docutils literal notranslate">ORG2</code> for it to be valid. Endorsement policies are what make Hyperledger Fabric different to other blockchains like Ethereum or Bitcoin. In these systems valid transactions can be generated by any node in the network. Hyperledger Fabric more realistically models the real world; transactions must be validated by trusted organizations in a network. For example, a government organization must sign a valid <code class="docutils literal notranslate">issueIdentity</code> transaction, or both the <code class="docutils literal notranslate">buyer</code> and <code class="docutils literal notranslate">seller</code> of a car must sign a <code class="docutils literal notranslate">car</code> transfer transaction. Endorsement policies are designed to allow Hyperledger Fabric to better model these types of real-world interactions. Finally, endorsement policies are just one example of <a class="reference external" href="../access_control.html#policies">policy</a> in Hyperledger Fabric. Other policies can be defined to identify who can query or update the ledger, or add or remove participants from the network. Indeed, policies themselves can define the rules by which they can be changed. And although an advanced topic, it is also possible to define <a class="reference external" href="../pluggable_endorsement_and_validation.html">custom endorsement policy</a> rules over and above those provided by Fabric. </section> <section id="valid-transactions"> <h2>Valid transactions<a class="headerlink" href="#valid-transactions" title="Link to this heading">¶</a></h2> When a smart contract executes, it runs on a peer node owned by an organization in the blockchain network. The contract takes a set of input parameters called the transaction proposal and uses them in combination with its program logic to read and write the ledger. Changes to the world state are captured as a transaction proposal response (or just transaction response) which contains a read-write set with both the states that have been read, and the new states that are to be written if the transaction is valid. Notice that the world state is not updated when the smart contract is executed! <img alt="smart.diagram4" src="../_images/smartcontract.diagram.04.png" /> All transactions have an identifier, a proposal, and a response signed by a set of organizations. All transactions are recorded on the blockchain, whether valid or invalid, but only valid transactions contribute to the world state. Examine the <code class="docutils literal notranslate">car transfer</code> transaction. You can see a transaction <code class="docutils literal notranslate">t3</code> for a car transfer between <code class="docutils literal notranslate">ORG1</code> and <code class="docutils literal notranslate">ORG2</code>. See how the transaction has input <code class="docutils literal notranslate">{CAR1, ORG1, ORG2}</code> and output <code class="docutils literal notranslate">{CAR1.owner=ORG1, CAR1.owner=ORG2}</code>, representing the change of owner from <code class="docutils literal notranslate">ORG1</code> to <code class="docutils literal notranslate">ORG2</code>. Notice how the input is signed by the application’s organization <code class="docutils literal notranslate">ORG1</code>, and the output is signed by both organizations identified by the endorsement policy, <code class="docutils literal notranslate">ORG1</code> and <code class="docutils literal notranslate">ORG2</code>. These signatures were generated by using each actor’s private key, and mean that anyone in the network can verify that all actors in the network are in agreement about the transaction details. A transaction that is distributed to all peer nodes in the network is validated in two phases by each peer. Firstly, the transaction is checked to ensure it has been signed by sufficient organizations according to the endorsement policy. Secondly, it is checked to ensure that the current value of the world state matches the read set of the transaction when it was signed by the endorsing peer nodes; that there has been no intermediate update. If a transaction passes both these tests, it is marked as valid. All transactions are added to the blockchain history, whether valid or invalid, but only valid transactions result in an update to the world state. In our example, <code class="docutils literal notranslate">t3</code> is a valid transaction, so the owner of <code class="docutils literal notranslate">CAR1</code> has been updated to <code class="docutils literal notranslate">ORG2</code>. However, <code class="docutils literal notranslate">t4</code> (not shown) is an invalid transaction, so while it was recorded in the ledger, the world state was not updated, and <code class="docutils literal notranslate">CAR2</code> remains owned by <code class="docutils literal notranslate">ORG2</code>. Finally, to understand how to use a smart contract or chaincode with world state, read the <a class="reference external" href="../developapps/chaincodenamespace.html">chaincode namespace topic</a>. </section> <section id="channels"> <h2>Channels<a class="headerlink" href="#channels" title="Link to this heading">¶</a></h2> Hyperledger Fabric allows an organization to simultaneously participate in multiple, separate blockchain networks via channels. By joining multiple channels, an organization can participate in a so-called network of networks. Channels provide an efficient sharing of infrastructure while maintaining data and communications privacy. They are independent enough to help organizations separate their work traffic with different counterparties, but integrated enough to allow them to coordinate independent activities when necessary. <img alt="smart.diagram5" src="../_images/smartcontract.diagram.05.png" /> A channel provides a completely separate communication mechanism between a set of organizations. When a chaincode definition is committed to a channel, all the smart contracts within the chaincode are made available to the applications on that channel. While the smart contract code is installed inside a chaincode package on an organizations peers, channel members can only execute a smart contract after the chaincode has been defined on a channel. The chaincode definition is a struct that contains the parameters that govern how a chaincode operates. These parameters include the chaincode name, version, and the endorsement policy. Each channel member agrees to the parameters of a chaincode by approving a chaincode definition for their organization. When a sufficient number of organizations (a majority by default) have approved to the same chaincode definition, the definition can be committed to the channel. The smart contracts inside the chaincode can then be executed by channel members, subject to the endorsement policy specified in the chaincode definition. The endorsement policy applies equally to all smart contracts defined within the same chaincode. In the example <a class="reference external" href="#channels">above</a>, a <code class="docutils literal notranslate">car</code> contract is defined on the <code class="docutils literal notranslate">VEHICLE</code> channel, and an <code class="docutils literal notranslate">insurance</code> contract is defined on the <code class="docutils literal notranslate">INSURANCE</code> channel. The chaincode definition of <code class="docutils literal notranslate">car</code> specifies an endorsement policy that requires both <code class="docutils literal notranslate">ORG1</code> and <code class="docutils literal notranslate">ORG2</code> to sign transactions before they can be considered valid. The chaincode definition of the <code class="docutils literal notranslate">insurance</code> contract specifies that only <code class="docutils literal notranslate">ORG3</code> is required to endorse a transaction. <code class="docutils literal notranslate">ORG1</code> participates in two networks, the <code class="docutils literal notranslate">VEHICLE</code> channel and the <code class="docutils literal notranslate">INSURANCE</code> network, and can coordinate activity with <code class="docutils literal notranslate">ORG2</code> and <code class="docutils literal notranslate">ORG3</code> across these two networks. The chaincode definition provides a way for channel members to agree on the governance of a chaincode before they start using the smart contract to transact on the channel. Building on the example above, both <code class="docutils literal notranslate">ORG1</code> and <code class="docutils literal notranslate">ORG2</code> want to endorse transactions that invoke the <code class="docutils literal notranslate">car</code> contract. Because the default policy requires that a majority of organizations approve a chaincode definition, both organizations need to approve an endorsement policy of <code class="docutils literal notranslate">AND{ORG1,ORG2}</code>. Otherwise, <code class="docutils literal notranslate">ORG1</code> and <code class="docutils literal notranslate">ORG2</code> would approve different chaincode definitions and would be unable to commit the chaincode definition to the channel as a result. This process guarantees that a transaction from the <code class="docutils literal notranslate">car</code> smart contract needs to be approved by both organizations. </section> <section id="intercommunication"> <h2>Intercommunication<a class="headerlink" href="#intercommunication" title="Link to this heading">¶</a></h2> A Smart Contract can call other smart contracts both within the same channel and across different channels. It this way, they can read and write world state data to which they would not otherwise have access due to smart contract namespaces. There are limitations to this inter-contract communication, which are described fully in the <a class="reference external" href="../developapps/chaincodenamespace.html#cross-chaincode-access">chaincode namespace</a> topic. </section> <section id="system-chaincode"> <h2>System chaincode<a class="headerlink" href="#system-chaincode" title="Link to this heading">¶</a></h2> The smart contracts defined within a chaincode encode the domain dependent rules for a business process agreed between a set of blockchain organizations. However, a chaincode can also define low-level program code which corresponds to domain independent system interactions, unrelated to these smart contracts for business processes. The following are the different types of system chaincodes and their associated abbreviations: <ul class="simple"> <li><code class="docutils literal notranslate">_lifecycle</code> runs in all peers and manages the installation of chaincode on your peers, the approval of chaincode definitions for your organization, and the committing of chaincode definitions to channels. You can read more about how <code class="docutils literal notranslate">_lifecycle</code> implements the Fabric chaincode lifecycle <a class="reference external" href="../chaincode_lifecycle.html">process</a>.</li> <li>Configuration system chaincode (CSCC) runs in all peers to handle changes to a channel configuration, such as a policy update. You can read more about this process in the following chaincode <a class="reference external" href="../configtx.html#configuration-updates">topic</a>.</li> <li>Query system chaincode (QSCC) runs in all peers to provide ledger APIs which include block query, transaction query etc. You can read more about these ledger APIs in the transaction context <a class="reference external" href="../developapps/transactioncontext.html">topic</a>.</li> <li>Endorsement system chaincode (ESCC) runs in endorsing peers to cryptographically sign a transaction response. You can read more about how the ESCC implements this <a class="reference external" href="../peers/peers.html#phase-1-proposal">process</a>.</li> <li>Validation system chaincode (VSCC) validates a transaction, including checking endorsement policy and read-write set versioning. You can read more about the VSCC implements this <a class="reference external" href="../peers/peers.html#phase-3-validation">process</a>.</li> </ul> It is possible for low level Fabric developers and administrators to modify these system chaincodes for their own uses. However, the development and management of system chaincodes is a specialized activity, quite separate from the development of smart contracts, and is not normally necessary. Changes to system chaincodes must be handled with extreme care as they are fundamental to the correct functioning of a Hyperledger Fabric network. For example, if a system chaincode is not developed correctly, one peer node may update its copy of the world state or blockchain differently compared to another peer node. This lack of consensus is one form of a ledger fork, a very undesirable situation.  </section> </section> </div> </div> <footer> <div class="rst-footer-buttons" role="navigation" aria-label="footer navigation"> <a href="../chaincode_lifecycle.html" class="btn btn-neutral float-right" title="Fabric chaincode lifecycle" accesskey="n" rel="next">Next </a> <a href="../orderer/ordering_service.html" class="btn btn-neutral" title="The Ordering Service" accesskey="p" rel="prev"> Previous</a> </div> <hr/> <div role="contentinfo"> © Copyright Hyperledger 2020-2024. This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</a> <a rel="license" href="http://creativecommons.org/licenses/by/4.0/"> <img alt="Creative Commons License" src="https://i.creativecommons.org/l/by/4.0/88x31.png" /></a> </div> Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>. </footer> </div> </div> </section> </div> <script> jQuery(function () { SphinxRtdTheme.Navigation.enable(true); }); </script> </body> </html>