POSE Practical Off-chain Smart Contract Execution Full Version Tommaso Frassetto Patrick Jauernig David Koisser David Kretzlery

2025-04-24 0 0 686.51KB 20 页 10玖币

侵权投诉

POSE: Practical Off-chain Smart Contract Execution

(Full Version)

Tommaso Frassetto∗, Patrick Jauernig∗, David Koisser∗, David Kretzler†,

Benjamin Schlosser†, Sebastian Faust†and Ahmad-Reza Sadeghi∗

Technical University of Darmstadt, Germany

∗ﬁrst.last@trust.tu-darmstadt.de

†ﬁrst.last@tu-darmstadt.de

Abstract—Smart contracts enable users to execute payments

depending on complex program logic. Ethereum is the most

notable example of a blockchain that supports smart contracts

leveraged for countless applications including games, auctions

and ﬁnancial products. Unfortunately, the traditional method of

running contract code on-chain is very expensive, for instance,

on the Ethereum platform, fees have dramatically increased,

rendering the system unsuitable for complex applications. A

prominent solution to address this problem is to execute code

off-chain and only use the blockchain as a trust anchor. While

there has been signiﬁcant progress in developing off-chain systems

over the last years, current off-chain solutions suffer from various

drawbacks including costly blockchain interactions, lack of data

privacy, huge capital costs from locked collateral, or supporting

only a restricted set of applications.

In this paper, we present POSE —a practical off-chain pro-

tocol for smart contracts that addresses the aforementioned

shortcomings of existing solutions. POSE leverages a pool of

Trusted Execution Environments (TEEs) to execute the computa-

tion efﬁciently and to swiftly recover from accidental or malicious

failures. We show that POSE provides strong security guarantees

even if a large subset of parties is corrupted. We evaluate our

proof-of-concept implementation with respect to its efﬁciency and

effectiveness.

I. INTRODUCTION

More than a decade ago, Bitcoin [46] introduced the

idea of a decentralized cryptocurrency, marking the advent

of the blockchain era. Since then, blockchain technologies

have rapidly evolved and a plethora of innovations emerged

with the aim to replace centralized platform providers by

distributed systems. One particularly important application

of blockchains concerns so-called smart contracts, complex

transactions executing payments that depend on programs

deployed to the blockchain. The ﬁrst and most popular

blockchain platform that supported complex smart contracts

is Ethereum [57]. However, Ethereum still falls short of the

decentralized “world computer” that was envisioned by the

community [50]. For example, contracts are replicated among

a large group of miners, thereby severely limiting scalability

and leading to high costs. As a result, most contracts used

in practice in the Ethereum ecosystem are very simple: 80%

of popular contracts consist of less than 211 instructions,

and almost half of the most active contracts are simple token

managers [48]. More recently proposed computing platforms

in permissionless decentralized settings (e.g., [1], [33]) suffer

from similar scalability limitations.

In recent years, numerous solutions have been proposed to

address these shortcomings of blockchains, one of the most

promising being so-called off-chain execution systems. These

protocols move the majority of transactions off-chain, thereby

minimizing the costly interactions with the blockchain. A

large body of work has explored various types of off-chain

solutions including most prominently state-channels [45], [26],

[22], Plasma [51], [36] and Rollups [47], [5], which are

actively investigated by the Ethereum research community.

Other schemes use execution agents that need to agree with

each other [59], [58], rely on incentive mechanisms [35],

[56], or leverage Trusted Execution Environments (TEEs) [20],

[25]. A core challenge that arises while designing off-chain

execution protocols is to handle the possibility of parties who

stop responding, either maliciously or accidentally. Without

countermeasures, this may cause the contract execution to

stop unexpectedly, which violates the liveness property. De-

spite major progress towards achieving liveness in a off-chain

setting, current solutions come with at least one of these

limitations: i participating parties need to lock large amounts

of collateral; ii costly blockchain interactions are required at

every step of the process or at regular intervals; and ﬁnally

iii the set of participants and the lifetime need to be known

beforehand, which limits the set of applications supported

by the system. Additionally, existing solutions often iv do

not support keeping the contract state conﬁdential, which is

required, e.g., for eBay-style proxy auctions [9] and games

such as poker. We refer the reader to Table II for an overview

on related work and to Section X for a detailed discussion.

Addressing all of these limitations in one solution while

guaranteeing liveness is highly challenging. Currently, there

are two ways to address the risks of unresponsive parties. The

ﬁrst approach is to require collateral, i.e., parties have to block

large amounts of money, which is used to disincentivize mali-

cious behavior and to compensate parties in case of premature

termination (cf. i ). Since the amount of collateral depends

on the number of participants and the amount of money in

the contract, both must be ﬁxed for the whole lifetime of the

contract. To ensure payout of the collateral, the lifetime of the

contract must be ﬁxed as well (cf. iii ). The second approach

is to store contract state on the blockchain to enable other

parties to resume execution. However, this is both expensive

and leads to long waiting times due to frequent synchronization

with the blockchain (cf. ii ). Further, if the contract state

needs to be conﬁdential, and hence, is not publicly veriﬁable,

verifying the correctness of the contract execution is harder

arXiv:2210.07110v1 [cs.CR] 13 Oct 2022

(cf. iv ). Realizing a system tackling all these challenges in a

holistic way could pave the way towards the envisioned “world

computer”. We will further elaborate on the speciﬁc challenges

in Section III.

Our goals and contributions: We present POSE , a novel

off-chain execution framework for smart contracts in permis-

sionless blockchains that overcomes these challenges, while

achieving correctness and strong liveness guarantees. In POSE ,

each smart contract runs on its own subset of TEEs randomly

selected from all TEEs registered to the network. One of the

selected TEEs is responsible for the execution of a smart

contract.

However, as the system hosting the executing TEE may be

malicious (e.g., the TEE could simply be powered off during

contract execution), our protocol faces the challenge of dealing

with malicious operator tampering, withholding and replaying

messages to/from the TEE. Hence, the TEE sends state updates

to the other selected TEEs, such that they can replace the

executing TEE if required. This makes POSE the ﬁrst off-

chain execution protocol with strong liveness guarantees. In

particular, liveness is guaranteed as long as at least one TEE in

the execution pool is responsive. Due to this liveness guarantee,

there is no inherent need for a large collateral in POSE (cf. i ).

The state remains conﬁdential, which allows POSE to have

private state (cf. iv ). Furthermore, POSE allows participants

to change their stake in the contract at any time. Thus,

POSE supports contracts without an a-priori ﬁxed lifetime and

enables the set of participants to be dynamic (cf. iii ). Above

all, POSE executes smart contracts quickly and efﬁciently

without any blockchain interactions in the optimistic case (cf.

ii ).

This enables the execution of highly complex smart con-

tracts and supports emerging applications to be run on the

blockchain, such as federated machine learning. Thus, POSE

improves the state of the art signiﬁcantly in terms of security

guarantees and smart contract features. To summarize, we list

our main contributions below:

•We introduce POSE , a fast and efﬁcient off-chain smart

contract execution protocol. It provides strong guarantees

without relying on blockchain interactions during opti-

mistic execution, and does not require large collaterals.

Moreover, it supports contracts with an arbitrary contract

lifetime and a dynamic set of users. An additional unique

feature of POSE is that it allows for conﬁdential state

execution.

•We provide a security analysis in a strong adversarial

model. We consider an adversary which may deviate

arbitrarily from the protocol description. We show that

POSE achieves correctness and state privacy as well as

strong liveness guarantees under static corruption, even in

a network with a large share of corrupted parties.

•To illustrate the feasibility of our scheme, we implement

a prototype of POSE using ARM TrustZone as the TEE

and evaluated it on practical smart contracts, including

one that can merge models for federated machine learning

in 238ms per aggregation.

II. ADVERSARY MODEL

The goal of POSE is to allow a set of users to run a

complex smart contract on a number of TEE-enabled systems.

Note, that POSE is TEE-agnostic and can be instantiated on

any TEE architecture adhering to our assumptions, similar to,

e.g., FastKitten [25]. In order to model the behavior and the

capabilities of every participant of the system, we make the

following assumptions:

A1: We assume the TEE to protect the enclave program, in

line with other TEE-assisted blockchain proposals [62], [25],

[20], [17], [63], [42]. Speciﬁcally:

A1.1: We assume the TEE to provide integrity and conﬁden-

tiality guarantees. This means that the TEE ensures that the

enclave program runs correctly, is not leaking any data, and is

not tampering with other enclaves. While our proof of concept

is based on TrustZone, our design does not depend on any

speciﬁc TEE. In practice, the security of a TEE is not always

ﬂawless, especially regarding information leaks. However,

plenty of mitigations exist for the respective commercial TEEs;

hence, we consider the problem of information leakage from

any speciﬁc TEE, as well as TEE-speciﬁc vulnerabilities in

security services, orthogonal to the scope of this paper. We dis-

cuss some mitigations to side-channel attacks to TrustZone, as

well as the possible grave consequences of a compromised or

leaking TEE for the executed smart contract, in Section VII-B.

A1.2: We further assume the adversaries to be unable to exploit

memory corruption vulnerabilities in the enclave program. This

could be ensured using a number of different approaches, e.g.,

by using memory-safe languages, by deploying a run-time

defense like CFI [11], or by proving the correctness of the

enclave program using formal methods. The existence of these

defenses can be proven through remote attestation (cf. A3).

A2: We assume the TEE to provide a good source of random-

ness to all its enclaves and to have access to a relative clock

according to the GlobalPlatform TEE speciﬁcation [31].

A3: We assume the TEE to support secure remote attestation,

i.e., to be able to provide unforgeable cryptographic proof that

a speciﬁc program is running inside of a genuine, authentic

enclave. Further, we assume the attestation primitive to allow

differentiation of two enclaves running the same code under the

same data. Note that today’s industrial TEEs support remote

attestation [3], [6], [8], [34], [55].

A4: We assume the TEE operators, i.e., the persons or or-

ganizations owning the TEE-enabled machines, to have full

control over those machines, including root access and control

over the network. The operators can, for instance, provide

wrong data to an enclave, delay the transmission of mes-

sages to it, or drop messages completely. The operators can

also completely disconnect an enclave from the network or

(equivalently) power off the machine containing it. However,

as stated in A1.1, the operators cannot leak data from any

enclave or inﬂuence its computation in any way besides by

sending (potentially malicious) messages to it through the

ofﬁcial software interfaces.

A5: We assume static corruption by the adversary. More

precisely, a ﬁxed fraction of all operators is corrupted while an

arbitrary number of users can be malicious (including the case

where they all are). We model each of the malicious parties as

byzantine adversaries, i.e., they can behave in arbitrary ways.

A6: We assume the blockchain used by the parties to satisfy

the following standard security properties: common preﬁx (ig-

noring the last γblocks, honest miners have an identical chain

preﬁx), chain quality (blockchain of honest miner contains

signiﬁcant fraction of blocks created by honest miners), and

chain growth (new blocks are added continuously). These

properties imply that valid transactions are included in one

of the next αblocks and that no valid blockchain fork of

length at least γcan grow with the same block creation rate

as the main chain. We deem protection against network attacks

(e.g., network partition attacks), which violate these standard

properties, orthogonal to our work.

III. DESIGN

POSE is a novel off-chain protocol for highly efﬁcient

smart contract execution, while providing strong correctness,

privacy, and liveness guarantees. To achieve this, POSE lever-

ages the integrity and conﬁdentiality guarantees of TEEs to

speed up contract execution and make signiﬁcantly more

complex contracts practical1. This is in contrast to execut-

ing contracts on-chain, where computation and veriﬁcation

is distributed over many parties during the mining process.

POSE supports contracts with arbitrary lifetime and number

of users, which includes complex applications like the well-

known CryptoKitties [2]. We elaborate more on interaction

between contracts in Appendix A. Our protocol involves users,

operators and a single on-chain smart contract. Users aim to

interact with smart contracts by providing inputs and obtaining

outputs in return. Operators own and manage the TEE-enabled

systems and contribute computing power to the POSE network

by creating protected execution units, called enclaves, using

their TEEs. These enclaves perform the actual state transitions

triggered by users. A simple on-chain smart contract, which

we call manager, is used to manage the off-chain enclave

execution units. In the optimistic case, when all parties behave

honestly, POSE requires only on-chain transactions for the

creation of a POSE contract as well as the locking and

unlocking of user funds. The smart contract execution itself

is done without any on-chain transactions.

A. Architecture Overview

Figure 1 illustrates the high-level working of POSE . Before

contract creation, there is already a set of enclaves that are

registered with the on-chain manager contract. The registration

process is explained in detail in Section V-E1. To create a

POSE contract, a user will initialize a contract creation with

the manager (Step 1), which includes a chosen enclave—out of

the registered set—to execute the off-chain contract creation.

In Step 2, the chosen creator enclave will setup the execution

pool for the given smart contract. In Figure 1, the pool size

is set to three; thus, the creator enclave will randomly select

three enclaves from the set of all enclaves registered in the

system (Step 3). In Step 4, the creator enclave will submit the

ﬁnalized contract information to the manager. This includes

the composition of the execution pool, i.e., a selected executor

enclave, which is responsible for executing the POSE contract,

as well as the watchdogs, ensuring availability. We elaborate

on this in-depth in Section V-E2. In Step 5, another user can

1We design POSE without depending on any speciﬁc TEE implementation.

In Section VII-B, we discuss the implications of using ARM TrustZone to

realize our scheme.

1. Contract

creation

initialization

Manager

6. Execute call

& sync Pool

3. Setup

Operator

Pool

4. Contract

creation

finalization

2. Contract

creation

request

5. Call on Contract

Contract

User

Creator

Enclave

Watchdog

Enclave

Watchdog

Enclave

Executor

Enclave

Contract

Blockchain

Fig. 1. Exemplary overview how POSE contracts are created (in blue) and

executed (in green).

now call the new contract by directly contacting the execu-

tor. Finally, for Step 6, the executor will execute the user’s

contract call and distribute the resulting state to the watchdog

enclaves, which conﬁrm the state update. See Section V-E3

for a detailed speciﬁcation of the execution protocol. If one

of the enclaves stops participating (e.g., due to a crash), the

dependent parties can challenge the enclave on the blockchain

(see Section V-E4). The dependent party can either be the user

awaiting response from the executor or the executor waiting

for the watchdogs’ conﬁrmation. For example, if the executor

stops executing the contract, the executor is challenged by the

user. A timely response constitutes a successful state transition

as requested by the user. Otherwise, if the current executor

does not respond, one of the watchdogs will ﬁll in as the new

executor. This makes POSE highly available, as long as at least

one watchdog enclave is dependable; thus, avoiding the need

for collateral to incentivize correct behavior. Further, POSE

supports private state, as the state is only securely shared with

other enclaves.

B. Design Challenges

We encountered a number of challenges while designing

POSE . We brieﬂy discuss them below.

Protection Against Malicious Operators. POSE ’s creator,

executor, and watchdogs are protected in isolated enclaves

running within the system, which is itself still under control of

a potentially malicious operator. Hence, operators can provide

arbitrary inputs, modify honest users’ messages, execute replay

attacks, and withhold incoming messages. Moreover, the sys-

tem and its TEE (i.e., enclaves) can be turned off completely

by its operator. In order to protect honest users from malicious

operators, we incorporate several security mechanisms. While

malicious inputs and modiﬁcation of honest users’ messages

can easily be prevented using standard measures like a se-

cure signature scheme, preventing withholding of messages is

more challenging. One particular reason is that for unreceived

messages, an enclave cannot differentiate between unsent and

stalled messages by the operator. Hence, we incorporate an on-

chain challenge-response procedure, which provides evidence

about the execution request and the existence of a response to

the enclave.

Achieving Strong Liveness Guarantees. We enable de-

pendent parties to challenge unresponsive operators via the

blockchain. The challenged operators either provide valid

responses over the blockchain that dependent parties can use

to ﬁnalize the state transition, or they are dropped from the

execution pool. In case an executor operator has been dropped,

we use the execution pool to resume the execution; this

requires state updates to be distributed to all watchdogs. With

at least one honest operator in the execution pool, the pool will

produce a valid state transition. Our protocol tolerates a ﬁxed

fraction of malicious operators as stated in our adversary model

(cf. Section II). By selecting the pool members randomly, we

guarantee with high probability that at least one enclave—

controlled by an honest operator—is part of the execution pool.

We show in Section VII-A that our protocol achieves strong

liveness guarantees.

Synchronization with the Blockchain. Some of the actions

taken by an enclave depend on blockchain data, e.g., de-

posits made by clients. Hence, it is crucial to ensure that

the blockchain data available to an enclave is consistent and

synchronized with the main chain. As an enclave does not

necessarily have direct access to the (blockchain) network, it

has to rely on the blockchain data provided by the operator.

However, the operator can tamper with the blockchain data

and, e.g., withhold blocks for a certain time. Thus, a major

challenge is designing a synchronization mechanism that (i)

imposes an upper bound on the time an enclave may lag behind

the main chain, (ii) prevents an operator from isolating an

enclave onto a fake side-chain, and (iii) ensures correctness and

completeness of the blockchain data provided to the enclave,

without (iv) requiring the enclave to validate or store the

entire blockchain. We present our synchronization mechanism

addressing these challenges in Section V-D.

Reducing Blockchain Interactions. Our system aims to min-

imize the necessary blockchain interactions to avoid expensive

on-chain computations. In the optimistic scenario, the only

on-chain transactions necessary are the contract creation and

the transfer of coins. The transfer transactions can also be

bundled to further reduce blockchain interactions. Note that the

virtualization paradigm known from state channels [26] can be

applied to our system. This enables parties to install virtual

smart contracts within existing smart contracts, and hence,

without any on-chain interactions at all. In the pessimistic

scenario, i.e., if operators fail to provide valid responses, they

have to be challenged, which requires additional blockchain

interactions.

Support of Private State. To support private state of ran-

domized contracts, careful design is required to avoid leakage.

While the conﬁdentiality guarantees of TEEs prevent any

data leakage during contract execution, our protocol needs

to ensure that an adversary cannot learn any information

except the output of a successful execution. In particular, in a

system where the contract state is distributed between several

parties, we need to prevent the adversary from performing an

execution on one enclave, learning the result, and exploiting

this knowledge when rolling back to an old state with another

enclave. This is due to the fact that a re-execution may use

different randomness or different inputs resulting in a different

output. We prevent these attacks by outputting state updates

to the users only if all pool members are aware of the new

state. Moreover, by solving the challenge of synchronization

between enclaves and the blockchain, we prevent an adversary

from providing a fake chain to the enclave, in which honest

operators are kicked from the execution pool. Such a fake

chain would allow an attacker to perform a parallel execution.

While results of the parallel (fake) execution cannot affect the

real execution, they can prematurely leak private data, e.g. the

winner in a private auction.

IV. DEFINITIONS & NOTATIONS

In the following, we introduce the cryptography primitives,

deﬁnition, and notations used in the POSE protocol.

Cryptographic Primitives. Our protocol utilizes a pub-

lic key encryption scheme (GenPK ,Enc,Dec), a signature

scheme (GenSig,Sign,Verify), and a secure hash function

H(·). All messages sent within our protocol are signed by the

sending party. We denote a message msigned by party Pas

(m;P). The veriﬁcation algorithm Verify(m0)takes as input a

signed message m0:= (m;P)and outputs ok if the signature

of Pon mis valid and bad otherwise. We identify parties by

their public keys and abuse notation by using Pand P’s public

key pkPinterchangeably. This can be seen as a direct mapping

from the identity of a party to the corresponding public key.

TEE. We comprise the hardware and software compo-

nents required to create conﬁdential and integrity-protected

execution environments under the term TEE. An operator can

instruct her TEE to create new enclaves, i.e., new execution

environments running a speciﬁed program. We follow the

approach of Pass et al. [49] to model the TEE functionality.

We brieﬂy describe the operations provided by the ideal

functionality formally speciﬁed in [49, Fig. 1]. A TEE provides

aTEE .install(prog)operation which creates a new enclave

running the program prog. The operation returns an enclave

id eid. An enclave with id eid can be executed multiple times

using the TEE .resume(eid,inp)operation. It executes prog

of eid on input inp and updates the internal state. This means

in particular that the state is stored across invocations. The

resume operation returns the output out of the program. We

slightly deviate from Pass et al. [49] and include an attestation

mechanism provided by a TEE that generates an attestation

quote ρover (eid,prog).ρcan be veriﬁed by using method

VerifyQuote(ρ). We consider only one instance Erunning the

POSE program per TEE. Therefore, we simplify the notation

and write E(inp)for TEE .resume(eid,inp).

Blockchain. We denote the blockchain by BC and the

average block time by τ. A block is considered ﬁnal if it

has at least γconﬁrmation blocks. Throughout the protocol

description in Section V-E, enclaves consider only transactions

included in ﬁnal blocks. Finally, we deﬁne that any smart

contact deployed to the blockchain is able to access the current

timestamp using the method BC.now and the hash of the most

recent 265 blocks [7] using the method BC.bh(i)where iis

the number of the accessed block. These features are available

on Ethereum.

V. THE POSE PROTOCOL

The POSE protocol considers four different roles: a man-

ager smart contract deployed to the blockchain, operators that

run TEEs, enclaves that are installed within TEEs, and users

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

POSE:PracticalOff-chainSmartContractExecution(FullVersion)TommasoFrassetto,PatrickJauernig,DavidKoisser,DavidKretzlery,BenjaminSchlossery,SebastianFaustyandAhmad-RezaSadeghiTechnicalUniversityofDarmstadt,Germanyrst.last@trust.tu-darmstadt.deyrst.last@tu-darmstadt.deAbstractSmartcontractsenab...

展开>> 收起<<

POSE Practical Off-chain Smart Contract Execution Full Version Tommaso Frassetto Patrick Jauernig David Koisser David Kretzlery.pdf

共20页,预览4页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

POSE Practical Off-chain Smart Contract Execution Full Version Tommaso Frassetto Patrick Jauernig David Koisser David Kretzlery

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: