Verifying and Displaying Move Smart Contract Source Code for

the Sui Blockchain

Rijnard van Tonder
MystenLabs, Inc.
USA
[email protected]

ABSTRACT condensed bytecode representation. This bytecode representation

Smart contract development presents additional challenges beyond strips away useful information in typical software development,
traditional software workflows, e.g., locally in IDEs. For smart con- like comments, docstrings, and syntax that help explain the imple-
tract developers to understand and trust code execution, they need mentation.
to write and use software libraries with a comprehensible code Just as in usual software development, smart contract developers
representation—i.e., source code. However, blockchains do not typ- generally need and depend on a source representation to write a
ically store the original source code of smart contracts, but a con- smart contract. The key difference is that developers must trust
densed bytecode representation. Thus, when developers consult that the source they are developing against corresponds to the
smart contract source code, they need to be sure that it corresponds bytecode that will be linked against their code on the blockchain.
to the same bytecode on the blockchain. Depending on available In general, a combination of trust and tooling can help ensure that
developer tools, this process can be ad-hoc, cumbersome, or opaque. such source code really is the same as the bytecode contract that is
In this paper we present our design and implementation of a new executable on the blockchain. For example, when developers decide
tool that serves to verify Move smart contract source code against to publish their smart contract on a blockchain, a tool could first
its bytecode representation on the Sui blockchain. We demonstrate check the integrity of the dependencies. The tool could compile
the user-facing shift where developers now benefit from seeing every source dependency into bytecode that the developer depends
source code in their browser instead of bytecode. We further high- on, and then check that the local output of bytecode matches the
light future features and research directions that verified source existing on-chain bytecode (that the yet-to-be-published smart
availability brings to smart contract developer experience. contract will depend on once published). When the source code
output corresponds to the expected on-chain bytecode, we say it is
KEYWORDS “verified”.
We’ve identified that developers on the Sui blockchain1 would
smart contracts, source code, bytecode, compilers, program com-
largely benefit from being able to see verified Move source code on-
prehension, software development, blockchain
line. Indeed, existing blockchains have varying support or pending
ACM Reference Format: requests for other languages [3, 6, 7]. However, every smart contract
Rijnard van Tonder. 2024. Verifying and Displaying Move Smart Contract language poses unique challenges to providing such a service, and
Source Code for the Sui Blockchain. In 2024 IEEE/ACM 46th International the constraints of a given blockchain and language will impose on
Conference on Software Engineering: Companion Proceedings (ICSE-Companion the feasibility, design, and implementation of a system to provide
’24), April 14–20, 2024, Lisbon, Portugal. ACM, New York, NY, USA, 4 pages.
such verified source code. This paper describes our exploration, im-
https://doi.org/10.1145/3639478.3640038
plementation, and result of designing a source verification service
for the Move language. While providing immediate value to devel-
1 INTRODUCTION opers, we also consider the service to be a fundamental building
Smart contract development presents additional challenges beyond block in unlocking greater developer user experience. For example,
traditional software workflows, e.g., locally in IDEs. The runtime source availability in the browser could allow for communicating
execution and output of a smart contract is wholly dependent on a software quality signals [11] and code navigation via the Language
distributed system that ensures the integrity of a blockchain. For Server Protocol [4].
smart contract developers to understand and trust code execution,
they need to write and use software libraries with a comprehensible 2 MOVE SOURCE VERIFICATION TOOL AND
code representation—i.e., source code. However, blockchains do not SERVICE
typically store the original source code of smart contracts, but a
Overview. The Move Source Verification Service (MSVS) serves
Permission to make digital or hard copies of all or part of this work for personal or Move source code that has been verified against its on-chain byte-
classroom use is granted without fee provided that copies are not made or distributed code representation. The service is powered by a tool implemented
for profit or commercial advantage and that copies bear this notice and the full citation in Rust, comprising:
on the first page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or • a backend server to clone source code, orchestrate verifica-
republish, to post on servers or to redistribute to lists, requires prior specific permission tion, and serve source code over a REST API.
and/or a fee. Request permissions from [email protected].
ICSE-Companion ’24, April 14–20, 2024, Lisbon, Portugal • a source-to-bytecode verification routine in a standalone
© 2024 Copyright held by the owner/author(s). Publication rights licensed to ACM. library (Rust crate).
ACM ISBN 979-8-4007-0502-1/24/04. . . $15.00
https://doi.org/10.1145/3639478.3640038 1 sui.io
ICSE-Companion ’24, April 14–20, 2024, Lisbon, Portugal Rijnard van Tonder

Figure 1: The pipeline illustrating how we verify smart contract code with MSVS. First, the reference source implementation is
pulled and compiled (1). The expected bytecode for the source is then pulled from the blockchain (2) and compared byte-for-byte
to the compiled source code (3). If the process succeeds, the source is displayed in the Sui Explorer frontend (4).

The implementation is open-source under MIT license.2 A hosted The central operation of the service is to effectively keep source
version of the tool3 integrates with suiexplorer.com, a web frontend code in lockstep with on-chain bytecode. One additional challenge
for exploring Sui blockchain data and code (see Figure 3 for a vi- in the Sui blockchain (and other blockchains supporting similar
sual example). The MSVS implementation is further independently operations) is the notion of smart contract upgrades. On the Sui
configurable and runnable (e.g., for developers who want to serve blockchain packages may be upgradable6 and our MSVS must ac-
their own source packages, or run the tool internally), and can be count for such changes to accurately report source. The server
integrated with alternative frontends beyond suiexplorer.com. Hard- currently implements threads that monitor changes to the fixed
ware requirements are generally low, and depends on the scale and addresses mentioned prior on the Sui blockchain. When a thread
number of source packages hosted. For example, we’ve deployed detects an on-chain upgrade (i.e., the bytecode changes on the
and tested the server on a single core machine with less than 512MB blockchain), the corresponding package source code is immediately
of RAM over a handful of standard Move library packages. invalidated on the server, so that it no longer reports that source
Tool and Service Operation. Figure 1 illustrates the pipeline when requested until the new code can be reverified. The server
for the Move Source Verification Service. The service 3 represents then pulls the source code again and repeats the verification process,
the tool presented in this paper: a server that orchestrates and im- which typically takes less than 10 seconds.
plements source verification to enable an end-to-end flow. At start Note that we do not derive (or decompile) the source code from
up, the server clones well-known source repositories containing the on-chain bytecode. Our service expects a repository containing
Move packages 1 . The set of source repositories are specified in a reference implementation to verify against. While decompiling
a configuration file, and target fixed branches in repositories. The is an attractive option when source code is unavailable, available
configuration may be modified as needed.4 Source packages are source containing comments and code formatting will remain the
expected to specify the on-chain address where the bytecode is preference of active developers. At present, a high quality decom-
published in a Move.toml file. The server uses this address to fetch piler for Move code does not yet exist.
the corresponding bytecode from the blockchain 2 . The server
builds the source code for each package and compares the output 3 DEVELOPER EFFORT, USER EXPERIENCE,
byte-for-byte to the expected bytecode found on-chain 3 . If this AND OPEN QUESTIONS
comparison succeeds, we say that the source code is verified. The
Increasing Developer Experience with User-facing Changes
server will then respond to API requests for source code from a
The before-and-after of our tool is illustrated by Figures 2 and 3,
frontend client (in this case, Sui Explorer) which are rendered to
and the main outcome of our approach. Previously, we displayed
users in the browser 4 .
only the Bytecode tab for modules (shown left). The Bytecode rep-
Cloning and verification is generally performed concurrently
resentation shows flat addresses when referencing other modules
per repository and package. In its first instantiation, the server
(e.g., 0x00..001:ascii). The corresponding Source representation
tracks four packages that roughly correspond to standard libraries,5
in Figure 3 reveals the namespaces and provides greater clarity (e.g.,
comprising roughly 18,000 lines of Move code. Verifying these
std::ascii instead). The source also reveals essential constants
packages takes around 8 seconds on our hosted service.
(which may be inlined during compilation) and documentation for
2 https://github.com/MystenLabs/sui/tree/main/crates/sui-source-validation-service
types and functions. Users can now largely benefit from source code
3 API hosted at source.mystenlabs.com
4 Click here to see the default configuration file online: configuration file online.
5 Find the packages online by clicking here. 6 https://docs.sui.io/build/package-upgrades
Verifying and Displaying Move Smart Contract Source Code for the Sui Blockchain ICSE-Companion ’24, April 14–20, 2024, Lisbon, Portugal

Figure 2: The bytecode representation of a Move smart contract on suiexplorer.com (cf. Move source code in Figure 3).

Figure 3: The source representation of the Move contract shown in Figure 2.

ICSE-Companion ’24, April 14–20, 2024, Lisbon, Portugal Rijnard van Tonder

availability, and in time, we are eager to build out additional fea- of source code discovery and verification to benefit their developer
tures such as code navigation (jumpt-to-definition, find-references) ecosystem.
uniquely for smart contracts in the browser.
Design of Planned Studies to Identify Developer Experi- 5 CONCLUSION
ence and Friction. At the time of writing, our MSVS is on the Enhancing developer productivity and ergonomics in the area
cusp of being put into production, and is not yet a mature tool. Our of smart contracts reveals a growing need for developers to eas-
primary research question is grounded in practice and industrial ap- ily access and understand source code they can trust. We identi-
plication: Is it feasible to design and build a service that ensures the fied unique requirements to enable source code views for the Sui
fidelity of smart contract source code for the Move language? What blockchain and implemented MSVS to meet those. We described
does a successful implementation entail, and does it meet the needs its implementation and operation as an essential building block for
of developers? Prior launched blockchains have demonstrated vari- the developer ecosystem. We anticipate that usage and subsequent
ous complexities that arise, and the possibility of forfeiting such a expansion of source-adjacent features (like quality indicators and
concept [3]. We have found that the exploration and design of an editor-like jump-to-definition functionality) will reveal ongoing
effective smart contract verification is not merely an engineering needs to sharpen developer tools for smart contracts.
exercise, and will continue to entail unknown complexities. For
example, we are currently evaluating how to support divergent ACKNOWLEDGMENTS
compilers that may emit different bytecodes, further complicating The author would like to acknowledge Ashok, Jk, and the engi-
the source verification process. Our main contribution with our neering team generally at Mysten Labs for help and support of this
tool is thus a demonstration of the feasibility and implementation work.
of a system that overcomes these initial challenges for the Move
language. REFERENCES
Upon launch, we plan to largely evaluate quantitative metrics [1] 2023. Discover the languages of Tezos. https://tezos.com/developers/languages.
around this service (how often active users consult the source Online; accessed 24 October 2023.
code in the browser out of all visitors) and build out new features [2] 2023. Ethereum Smart Contract Languages. https://ethereum.org/en/developers
/docs/smart-contracts/languages. Online; accessed 24 October 2023.
that specifically require trusted source code to be available. For [3] 2023. Feature Request: Possibility to Verify Source For Tezos Smart Contracts.
example, we are interested in evaluating and surfacing software https://gitlab.com/tezos/tezos/-/issues/4491. Online; accessed 24 October 2023.
[4] 2023. Language Server Protocol. https://microsoft.github.io/language-server-
quality metrics [8–10, 12]) to help give users the signals they need to protocol. Online; accessed 24 October 2023.
trust a given smart contract. One practical example shows that the [5] 2023. Solana Rust Program Quickstart. https://docs.solana.com/getstarted/rust.
presence of repository badges can help to assess quality assurance Online; accessed 24 October 2023.
[6] 2023. Solidity Verified Contract. https://etherscan.io/token/0x0AaCfbeC6a2475
in open source software [11]. Likewise, we seek corresponding 6c20D41914F2caba817C0d8521#code. Online; accessed 24 October 2023.
signals, such as badges, to display alongside smart contract source [7] 2023. What is Anchor and the Anchor Program Registry? https://www.alchemy.
to surface software quality signals. Our MSVS is the basic building com/overviews/solana-anchor. Online; accessed 24 October 2023.
[8] Allan J. Albrecht and John E. Gaffney Jr. 1983. Software Function, Source Lines
block to unlock these studies and better understand the unique of Code, and Development Effort Prediction: A Software Science Validation. IEEE
needs of Move smart contract developers. Trans. Software Eng. 9, 6 (1983), 639–648.
[9] Eirini Kalliamvakou, Daniela E. Damian, Kelly Blincoe, Leif Singer, and Daniel M.
Germán. 2015. Open Source-Style Collaborative Development Practices in Com-
4 RELATED WORK mercial Projects Using GitHub. In International Conference on Software Engineer-
ing (ICSE ’15). 574–585.
Blockchains and supported smart contract languages exist in var- [10] Sandra Slaughter, Donald E. Harter, and Mayuram S. Krishnan. 1998. Evaluating
ious flavors [1, 2, 5], and all impose unique constraints and chal- the Cost of Software Quality. Commun. ACM 41, 8 (1998), 67–73.
[11] Asher Trockman, Shurui Zhou, Christian Kästner, and Bogdan Vasilescu. 2018.
lenges in their respective developer ecosystems. The Sui blockchain Adding sparkle to social coding: an empirical study of repository badges in the
is no different, and in general the approach and implementation npm ecosystem. In International Conference on Software Engineering (ICSE). ACM,
of our Move Source Verification Service address these uniquely 511–522.
[12] Stefan Wagner, Klaus Lochmann, Lars Heinemann, Michael Kläs, Adam Trendow-
and in new ways, particularly with respect to: (1) smart contract icz, Reinhold Plösch, Andreas Seidl, Andreas Goeb, and Jonathan Streit. 2012. The
bytecode representation, and the ability to compare locally com- Quamoco product quality modelling and assessment approach. In International
piled bytecode to on-chain bytecode; (2) accounting for source Conference on Software Engineering (ICSE ’12). 1133–1142.

changes in the presence of our unique package upgrade process;7

and (3) identifying challenges and striving for solutions that cause
developer friction for the Move language. At a more general level,
existing work in practice identifies the importance of linking to
source repositories, for example, the Anchor Program Registry on
the Solana blockchain [7]. On Ethereum, etherscan supports ren-
dering source code for, e.g., the Solidity language [6]. The Tezos
issue tracker contains an open feature request for verifying source
code similar to the approach we’ve implemented [3]. Overall, in the
state of practice, most blockchain languages benefit from some level

7 https://docs.sui.io/build/package-upgrades