The Fight Goes on Forever: “Limited Government” and the First Bank of the United States

Conservative jurists and politicians argue that the “Framers” wanted limited government. But the First Congress, with eighteen men who participated in the Constitutional Convention as members of either the Senate or the House of Representatives, overwhelmingly supported Alexander Hamilton’s plan for the First Bank of the United States, and rejected James Madison’s arguments that chartering a bank was beyond the enumerated powers granted Congress under the Constitution. Most of the framers in the first government, in other words, rejected Madison’s views, and hence the view of modern conservatives, on limited government

REVIS: An Error Visualization Tool for Rust

Rust is a programming language that uses a concept of ownership to guarantee memory safety without the use of a garbage collector. However, some error messages related to ownership can be difficult to understand and fix, particularly those that depend on value lifetimes. To help developers fix lifetime-related errors, we developed REVIS, a VSCode extension that visualizes lifetime-related Rust compiler errors. We describe the design and implementation of the VSCode extension, along with a preliminary evaluation of its efficacy for student learners of Rust. Although the number of participants was too low to enable evaluation of the efficacy of REVIS, we gathered data regarding the prevalence and time to fix the compiler errors that the participants encountered.Comment: Presented at HATRA 202

Short Paper: Blockcheck the Typechain

Recent efforts have sought to design new smart contract programming languages that make writing blockchain programs safer. But programs on the blockchain are beholden only to the safety properties enforced by the blockchain itself: even the strictest language-only properties can be rendered moot on a language-oblivious blockchain due to inter-contract interactions. Consequently, while safer languages are a necessity, fully realizing their benefits necessitates a language-aware redesign of the blockchain itself. To this end, we propose that the blockchain be viewed as a typechain: a chain of typed programs-not arbitrary blocks-that are included iff they typecheck against the existing chain. Reaching consensus, or blockchecking, validates typechecking in a byzantine fault-tolerant manner. Safety properties traditionally enforced by a runtime are instead enforced by a type system with the aim of statically capturing smart contract correctness. To provide a robust level of safety, we contend that a typechain must minimally guarantee (1) asset linearity and liveness, (2) physical resource availability, including CPU and memory, (3) exceptionless execution, or no early termination, (4) protocol conformance, or adherence to some state machine, and (5) inter-contract safety, including reentrancy safety. Despite their exacting nature, typechains are extensible, allowing for rich libraries that extend the set of verified properties. We expand on typechain properties and present examples of real-world bugs they prevent

Securing Smart Contract On The Fly

We present Solythesis, a source to source Solidity compiler which takes a smart contract code and a user specified invariant as the input and produces an instrumented contract that rejects all transactions that violate the invariant. The design of Solythesis is driven by our observation that the consensus protocol and the storage layer are the primary and the secondary performance bottlenecks of Ethereum, respectively. Solythesis operates with our novel delta update and delta check techniques to minimize the overhead caused by the instrumented storage access statements. Our experimental results validate our hypothesis that the overhead of runtime validation, which is often too expensive for other domains, is in fact negligible for smart contracts. The CPU overhead of Solythesis is only 0.12% on average for our 23 benchmark contracts