ETSI GS PDL 011 V2.1.1 (2022-09)

Permissioned Distributed Ledger (PDL); Specification of Requirements for Smart Contracts' architecture and security

RGS/PDL-0011v211_SC_Arch_Sec

General Information

• Status: Not Published
• Technical Committee: PDL - Permissioned Distributed Ledger
• Current Stage: 12 - Completion
• Due Date: 29-Sep-2022
• Completion Date: 21-Sep-2022

Standards Content (Sample)

GROUP SPECIFICATION
Permissioned Distributed Ledger (PDL);
Specification of Requirements for Smart Contracts'
architecture and security
Disclaimer
The present document has been produced and approved by the Permissioned Distributed Ledger (PDL) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS PDL 011 V2.1.1 (2022-09)

Reference
RGS/PDL-0011v211_SC_Arch_Sec
Keywords
PDL, policies, smart contract
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.
ETSI
3 ETSI GS PDL 011 V2.1.1 (2022-09)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
Executive summary . 6
Introduction . 7
1 Scope . 8
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 10
3.3 Abbreviations . 10
4 Define the Properties of Smart Contracts . 10
4.1 Introduction . 10
4.2 Challenges . 10
4.2.1 Inherent Properties . 10
4.2.1.1 Immutability . 10
4.2.1.2 Transparency . 11
4.2.1.3 Auto-Executable . 11
4.2.2 Interoperability/Ledger Dependency . 11
4.2.3 Scalability . 11
4.2.4 Synchronization of Offline Smart Contracts . 12
4.2.5 Ledger Time Synchronization. 12
4.3 Actors in a Smart Contract . 12
4.4 Smart Contract Policy Governance . 12
5 Requirements for Designing a Smart Contract . 12
5.1 Smart Contract Facets . 12
5.1.1 Introduction. 12
5.1.2 Foundational Role . 12
5.1.3 Functional Role . 12
5.1.4 Business/Operational Role . 13
5.2 Actors . 13
5.2.1 Introduction. 13
5.2.2 Lifecycle Management . 13
5.2.3 Owner . 13
5.2.4 Stakeholders . 13
5.2.5 Requirements During Design . 13
5.2.5.1 Lifecycle . 13
5.2.6 Available Technologies . 14
5.2.7 Auditability . 14
5.2.7.1 Auditable Code and Libraries . 14
5.2.7.2 Auditability of Implementation . 14
5.2.8 Input to the Smart Contracts . 15
5.2.9 Universal Clock . 15
5.2.10 Terminatable . 15
5.2.11 Security . 15
6 Solutions for Architecture and Functional Modelling . 15
6.1 Introduction . 15
6.2 Smart Contract Offloading . 16
6.2.1 Introduction. 16
6.2.2 Requirements for the External Storages. 16
ETSI
4 ETSI GS PDL 011 V2.1.1 (2022-09)
6.2.3 Requirements for External Smart Contracts . 17
6.2.4 Home-PDL Managed Storage . 17
6.2.4.1 Non-PDL External Storage . 17
6.2.4.2 HPN Managed Sidechain . 18
6.2.5 Non-HPN Sources Managed Storages . 19
6.2.5.1 Introduction . 19
6.2.5.2 Non-HPN Mainchain . 19
6.2.5.3 Non-HPN Sidechain . 19
6.2.5.4 Third-Party Managed External Storage . 20
6.2.6 Modularized Smart Contracts . 20
6.2.6.1 Introduction . 20
6.2.6.2 Sidechain Offloading . 21
6.2.6.3 HPN-Managed Datacentre . 22
6.2.6.4 Non-HPN PDL Smart Contract Split . 23
6.2.6.4.1 Non-HPN Mainchain . 23
6.2.6.4.2 Non-HPN Sidechain . 23
6.2.6.5 External and Shared Storages Among PDLs . 24
6.2.6.6 Time-Dependent Smart Contracts . 24
6.2.6.7 Smart Contract Time/Timers . 24
6.2.7 Data Integrity Sanity Checking . 25
6.3 Architectural and Functional Requirements . 25
6.3.1 Lifecycle of a Smart Contract . 25
6.3.2 Template Contracts . 26
6.3.3 Time-Limited . 26
6.3.4 Internal Termination . 26
6.3.5 Safe Termination . 27
6.3.6 Destruction . 27
6.3.7 Secure Access Control Mechanisms . 28
6.3.7.1 Introduction . 28
6.3.7.2 Access - Control Requirements for delegates . 29
6.3.8 Control Instructions . 29
6.3.9 Archiving the data . 30
6.3.10 Stale data . 31
6.3.11 Updates . 31
6.3.12 Smart Contract Fields . 31
6.3.13 Mandatory Fields . 31
6.3.14 Fixed/Permanent . 31
6.3.15 Parameterized . 32
6.3.16 Optional Fields . 32
6.4 Architecture and Functional Descriptions . 33
6.4.1 Required Functions . 33
6.4.1.1 Initialization . 33
6.4.1.2 Access-Control . 34
6.4.1.3 Logic . 34
6.4.1.4 Entry Functions . 34
6.4.1.5 Termination Function . 35
6.4.2 Example Architecture of a Smart Contract . 36
6.4.2.1 Smart Contract with External Input . 36
6.4.2.2 Smart Contract with another smart contract . 37
7 Data Inputs and Outputs . 37
7.1 Introduction . 37
7.2 Generalized Input/Output Requirements . 37
7.3 Internal Data Inputs . 38
7.3.1 Introduction. 38
7.3.1.1 Internal Inputs Options . 38
7.3.1.2 HPN Participants . 38
7.3.1.3 HPN Smart Contracts . 38
7.3.2 Requirements for Internal Outputs . 39
7.4 External Data Inputs . 39
7.4.1 Non-HPN . 39
7.4.1.1 Introduction . 39
ETSI
5 ETSI GS PDL 011 V2.1.1 (2022-09)
7.4.1.2 Faster Approach . 39
7.4.1.3 Secured Approach . 40
7.5 Oracles . 40
7.5.1 Introduction. 40
7.5.2 Requirements for oracles . 41
7.5.3 Oracles' Access Rights . 41
7.5.4 Oracles as Internal Service. 41
7.5.5 Oracle from External Sources . 42
7.5.6 Criteria for Oracles Services Approval . 42
7.5.7 Offline Oracles . 43
8 Governance Role in Smart Contracts . 43
8.1 Introduction . 43
8.2 Governance Role Delegated to Policy of Smart Contract . 43
8.3 Updating a smart contract . 44
8.4 Operational Decisions . 44
8.5 Termination of contract . 44
8.6 General Compliance Strategies for Smart Contracts . 45
9 Testing Smart Contracts . 45
9.1 Introduction . 45
9.2 Testing Strategies . 46
9.3 Generalized Testing Targets . 46
9.4 Testing Checklist . 46
9.5 Offline Testing . 47
9.5.1 Introduction. 47
9.5.2 Sandbox Testing . 47
9.5.3 Testbeds . 48
9.6 Online Monitoring . 48
9.6.1 Introduction. 48
9.6.2 Time-Limited Test . 48
9.6.3 Monitoring . 48
9.6.4 Online Reports . 48
9.6.5 Decisions Based on the Reports . 49
10 Updating a Smart Contract . 49
10.1 Introduction . 49
10.2 Update Situations . 49
10.3 Strategies of Updating . 49
10.3.1 Old Version . 49
10.3.2 Technological Upgrades . 50
10.3.3 Upgrading Through Versioning . 50
10.3.4 Updating Steps . 50
10.3.5 Checklist Before Redeployment . 50
10.3.6 Securely Inactivating Old Contract . 51
11 Threats and Security . 51
11.1 Introduction . 51
11.2 Threats . 51
11.2.1 Smart Contract Programming Errors . 51
11.2.2 Internal Threats . 51
11.2.2.1 Transactions Ordering . 51
11.2.2.2 Malicious/Accidental Executions . 52
11.2.2.3 Reporting Wrong Parameters . 52
11.2.3 External Threats . 52
11.2.3.1 Introduction . 52
11.2.3.2 Malicious Oracles . 53
11.2.3.3 Accidental Damages. 53
11.2.3.4 Malicious Attacks . 53
11.2.3.5 Denial of Service Attack . 53
11.2.3.6 Re-entrancy Attack. 53
11.2.3.7 Numerical/Integer Overflow attack . 53
History . 54
ETSI
6 ETSI GS PDL 011 V2.1.1 (2022-09)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Permissioned
Distributed Ledger (PDL).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document discusses the challenges and requirements of viable deployment of smart contracts for industries.
The challenges due to inherent properties of smart contracts, and also due to external and internal interaction are
discussed and their solutions are presented.
ETSI
7 ETSI GS PDL 011 V2.1.1 (2022-09)
Introduction
The present document extends the discussion of challenges and requirements for the successful adoption of smart
contracts. The present document discusses the current challenges of smart contracts' deployment and outlines
architecture requirements that can mitigate those problems and enable error-free and efficient smart contracts.
Moreover, the present document also oversees smart contracts' security aspects and explains internal and external
threats to a smart contract and presents possible mitigation techniques for them.

ETSI
8 ETSI GS PDL 011 V2.1.1 (2022-09)
1 Scope
The present document establishes the architectural and functional specifications of smart contracts, additionally,
highlights the potential threats and specifies the solutions to mitigate them, requirements on the use of technology for
smart contracts, governance, purpose, motivation and security.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI GR PDL 004: "Permissioned Distributed Ledgers (PDL); Smart Contracts; System
Architecture and Functional Specification".
NOTE: Available at
https://www.etsi.org/deliver/etsi_gr/PDL/001_099/004/01.01.01_60/gr_PDL004v010101p.pdf.
[i.2] ETSI GR PDL 010: "PDL Operations in Offline Mode".
NOTE: Available at
https://www.etsi.org/deliver/etsi_gr/PDL/001_099/010/01.01.01_60/gr_PDL010v010101p.pdf.
[i.3] ETSI GS PDL 012: "Permissioned Distributed ledger (PDL); Reference Architecture".
NOTE: Available at
https://www.etsi.org/deliver/etsi_gs/PDL/001_099/012/01.01.01_60/gs_PDL012v010101p.pdf.
[i.4] ETSI GR PDL 006: "Permissioned Distributed Ledger (PDL); Inter-Ledger interoperability".
NOTE: Available at
https://www.etsi.org/deliver/etsi_gr/PDL/001_099/006/01.01.01_60/gr_PDL006v010101p.pdf.
ETSI
9 ETSI GS PDL 011 V2.1.1 (2022-09)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
auditable library: complete code and its dependencies of a library is available for free to audit
auditable smart contract: code of the contract and all its internal libraries which are available for audit purposes
contract administrator: entity which is responsible for managing and executing the smart contract
NOTE: In the cases, when the smart contract is shared among multiple participants the governance of the PDL is
the owner of the contract.
contract expiration time: time when the governance will call the self-destruct clause to destruct a smart contract
contract owner: entity installed the smart contract
eternal contract type: lack in without internal termination function
governance time: governance clock
Home PDL-Network (HPN): when all the permanent nodes belong to the same PDL network
mainchain: formed at the formation of the consortium and is not dependent on any other chain
off-chain contract type: smart contract not installed on the mainchain
on-chain contract type: smart contract installed on the mainchain
oracles: service that sends data to/from a PDL
® ®
NOTE: It should not be confused with the commercial company product name ORACLE by Sun
Microsystems.
replicated contract type: different smart contract versions active at the same time
sidechain: sub-chain of the mainchain
smart contract entry functions: smart contract functions which provide access to a contract from outside world
stakeholders: all the parties benefitted from the smart contract deployment, execution and destruction
smart contract timers: timers that keeps track of the smart contract active/inactive time:
• long-term timers: lasts the lifecycle of the smart contract. Contract creation to destruction
• short-term timers: duration of an execution of a smart contract. contract initialization until its termination
template contract type: contract stored in ledger which are generalized to be reused by several participants through
parametrised executions
termination: Suspend a smart contract:
• termination: can be reused with different parameters or can be revised with minor changes
- natural termination: after completing the task
- interrupt termination: during the task
• destruction: completed its life cycle - cannot be used anymore.
ETSI
10 ETSI GS PDL 011 V2.1.1 (2022-09)
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
A/D Analogue/Digital
ACL Access Control List
AI Artificial Intelligence
API Application Programming Interface
CD Continuous Delivery
CI Continuous Integration
CPU Central Processing Unit
DLT Distributed Ledger Technology
HPN Home PDL-Network
ID IDentity
IPR Intellectual Property Rights
ML Machine Learning
PDL Permissioned Distributed Ledger
QoS Quality of Service
SC Smart Contract
SSL Secure Socket Layer
TEE Trusted Execution Environment
UTC Universal Time Coordinated
4 Define the Properties of Smart Contracts
4.1 Introduction
Smart Contracts are executable codes which are installed on DLTs (i.e. PDLs for the purpose the present document),
therefore their characteristics are dependent on their underlying ledger technology. Some of these characteristics such as
immutability and transparency are by-design properties of a PDL and hence common to all PDL-types. Smart contracts
inherit these properties from PDLs.
In this clause, such challenges which shall be taken care when designing smart contracts are highlighted.
4.2 Challenges
4.2.1 Inherent Properties
4.2.1.1 Immutability
Smart Contracts are immutable, which means an already registered smart contract cannot be modified or deleted and
cannot be tampered with. This way, the integrity of a contract is guaranteed; that is to say, a contractual agreement
installed as a smart contract on a PDL becomes ossified, and none of the participants can make any changes
retroactively. Immutability produces tamperproof contracts and prevents document frauds. However, immutability
comes with a cost of scalability and has two significant problems:
• An expired contract (or smart contract) - Even a smart contract that is expired, still lives on the ledger and
occupies the storage. For example, if a vendor and an operator are in a contract; the contract may be
valid/active for some certain duration and will expire. Such contracts if installed as smart contracts cannot be
deleted from the ledger, and cause scalability problem.
ETSI
11 ETSI GS PDL 011 V2.1.1 (2022-09)
• Erroneous contracts (or smart contracts) - If a smart contract has bugs or errors, it can make unwanted and
unintentional, possibly harmful transactions. It is to be noted here that all the transactions either wanted or
unwanted are recorded in a PDL. A bug-free and corrected contract may replace the old contract, but records
already stored in the PDL cannot be altered.
4.2.1.2 Transparency
In PDLs, all the ledger nodes keep an identical copy of a ledger; this means they all share the same information. As a
result, all the transactions are transparent or known to all the participants of the PDL. Hence, none of them can deny the
details of a transaction. In certain cases, or events, when some of the participants of a PDL want private dealings,
transparency is not required and may not even defeat the purpose of privacy. For example, a sub-group of participants in
a large PDL want to do some business and install a smart contract for the contractual terms and do not want to reveal
their contractual details to the rest of the PDL users. In a typical PDL every node will have a copy of this contract but
here a private smart contract is required.
A possible solution to this challenge would be private chains or private channels, such as implementation of private
channels in Hyperledger Fabric, in where smart contracts can be installed on separate, private channels only visible to
the sub-group involved in a contract.
4.2.1.3 Auto-Executable
Smart contracts are triggered by a software condition and can even be executed without human intervention. Auto-
executable smart contracts provide an automated method of contracts' execution in which parties can install the
contracts as smart contracts which are executed by the code itself. However, this property instigates the following
challenges:
• Uncontrollable executions - Erroneous code can trigger uncontrollable executions. As an example, unwanted
automated payments may cause monetary losses or delivery of incorrect amount of goods due to
uncontrollable and out-of-order delivery instruction.
• Malicious executions - If malicious parties create backdoors to a smart contract, they can execute smart
contracts and it may
...