Researcher profile

Sam Blackshear

Sam Blackshear contributes to research discovery and scholarly infrastructure.

ResearcherAffiliation not importedOpen to collaborate

Trust snapshot

Quick read

Trust 15 - UnverifiedVerification L1Unclaimed author
3works
0followers
1topics
4close collaborators

Actions

Decide how to stay connected

Follow researcher0

Identity and collaboration

How to connect with this researcher

Claiming links this public author record to a researcher profile and unlocks direct collaboration workflows.

Log in to claim

Direct collaboration

Open a focused conversation when the fit is right

Claim this author entity first to unlock direct invitations.

Research graph

See the researcher in context

Open full explorer

Inspect adjacent work, topics, institutions and collaborators without jumping out to a separate graph page.

Building this graph slice

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

3 published item(s)

preprint2022arXiv

Robust Safety for Move

A program that maintains key safety properties even when interacting with arbitrary untrusted code is said to enjoy \emph{robust safety}. Proving that a program written in a mainstream language is robustly safe is typically challenging because it requires static verification tools that work precisely even in the presence of language features like dynamic dispatch and shared mutability. The emerging \move programming language was designed to support strong encapsulation and static verification in the service of secure smart contract programming. However, the language design has not been analyzed using a theoretical framework like robust safety. In this paper, we define robust safety for the \move language and introduce a generic framework for static tools that wish to enforce it. Our framework consists of two abstract components: a program verifier that can prove an invariant holds in a closed-world setting (e.g., the Move Prover), and a novel \emph{encapsulator} that checks if the verifier's result generalizes to an open-world setting. We formalise an escape analysis as an instantiation of the encapsulator and prove that it attains the required security properties. Finally, we implement our encapsulator as an extension to the Move Prover and use the combination to analyze a representative benchmark set of real-world \move programs. This toolchain certifies $>$99\% of the \move modules we analyze, validating that automatic enforcement of strong security properties like robust safety is practical for \move.

preprint2022arXiv

The Move Borrow Checker

The Move language provides abstractions for programming with digital assets via a mix of value semantics and reference semantics. Ensuring memory safety in programs with references that access a shared, mutable global ledger is difficult, yet essential for the use-cases targeted by Move. The language meets this challenge with a novel memory model and a modular, intraprocedural static reference safety analysis that leverages key properties of the memory. The analysis ensures the absence of memory safety violations in all Move programs (including ones that link against untrusted code) by running as part of a load-time bytecode verification pass similar to the JVM [12] and CLR [15]. We formalize the static analysis and prove that it enjoys three desirable properties: absence of dangling references, referential transparency for immutable references, and absence of memory leaks.

preprint2020arXiv

Resources: A Safe Language Abstraction for Money

Smart contracts are programs that implement potentially sophisticated transactions on modern blockchain platforms. In the rapidly evolving blockchain environment, smart contract programming languages must allow users to write expressive programs that manage and transfer assets, yet provide strong protection against sophisticated attacks. Addressing this need, we present flexible and reliable abstractions for programming with digital currency in the Move language [Blackshear et al. 2019]. Move uses novel linear [Girard 1987] resource types with semantics drawing on C++11 [Stroustrup 2013] and Rust [Matsakis and Klock 2014]: when a resource value is assigned to a new memory location, the location previously holding it must be invalidated. In addition, a resource type can only be created or destroyed by procedures inside its declaring module. We present an executable bytecode language with resources and prove that it enjoys resource safety, a conservation property for program values that is analogous to conservation of mass in the physical world.