No abstract

Callbacks are essential in many programming environments, but drastically complicate program understanding and reasoning because they allow to mutate object's local states by external objects in unexpected fashions, thus breaking modularity. The famous DAO bug in the cryptocurrency framework Ethereum, employed callbacks to steal $150M. We define the notion of Effectively Callback Free (ECF) objects in order to allow callbacks without preventing modular reasoning.An object is ECF in a given execution trace if there exists an equivalent execution trace without callbacks to this object. An object is ECF if it is ECF in every possible execution trace. We study the decidability of dynamically checking ECF in a given execution trace and statically checking if an object is ECF. We also show that dynamically checking ECF in Ethereum is feasible and can be done online. By running the history of all execution traces in Ethereum, we were able to verify that virtually all existing contract executions, excluding these of the DAO or of contracts with similar known vulnerabilities, are ECF. Finally, we show that ECF, whether it is verified dynamically or statically, enables modular reasoning about objects with encapsulated state.

Callbacks are an effective programming discipline for implementing event-driven programming, especially in environments like Ethereum which forbid shared global state and concurrency. Callbacks allow a callee to delegate the execution back to the caller. Though effective, they can lead to subtle mistakes principally in open environments where callbacks can be added in a new code. Indeed, several high profile bugs in smart contracts exploit callbacks. We present the first static technique ensuring modularity in the presence of callbacks and apply it to verify prominent smart contracts. Modularity ensures that external calls to other contracts cannot affect the behavior of the contract. Importantly, modularity is guaranteed without restricting programming. In general, checking modularity is undecidable—even for programs without loops. This paper describes an effective technique for soundly ensuring modularity harnessing SMT solvers. The main idea is to define a constructive version of modularity using commutativity and projection operations on program segments. We believe that this approach is also accessible to programmers, since counterexamples to modularity can be generated automatically by the SMT solvers, allowing programmers to understand and fix the error. We implemented our approach in order to demonstrate the precision of the modularity analysis and applied it to real smart contracts, including a subset of the 150 most active contracts in Ethereum. Our implementation decompiles bytecode programs into an intermediate representation and then implements the modularity checking using SMT queries. Overall, we argue that our experimental results indicate that the method can be applied to many realistic contracts, and that it is able to prove modularity where other methods fail.

No abstract

No abstract

No abstract

Introduction There is limited data on the long-term follow-up of patients with myocarditis. Aim To investigate the long-term follow-up of patients with myocarditis. Material and methods We performed a retrospective observational analysis on the clinical long-term outcomes of patients with myocarditis over a 10-year period. The primary outcome was mortality. We identified risk factors for mortality and adverse clinical outcomes. We also compared the characteristics and outcomes of patients presenting with fulminant myocarditis to those presenting with non-fulminant myocarditis. Results Between May 2004 and December 2014, 203 patients with myocarditis or perimyocarditis were admitted to our center. Most patients were male (87.7%) with a median age at presentation of 33 years (interquartile range: 25.4–38.9). The median follow-up period was 56.9 months (interquartile range 25.3–87.3 months), during which the overall mortality was 4.4% (9 patients). Fifteen patients presented with fulminant myocarditis. After multivariable analysis, older age (HR = 1.11, 95% CI: 1.05–1.16, p < 0.001) and a poorer New York Heart Association (NYHA) function class (HR = 4.6, 95% CI: 1.18–18, p = 0.028) were found to be independently associated with a higher risk of mortality, whereas higher albumin levels at presentation (HR = 0.2, 95% CI: 0.07–0.56, p = 0.002) were associated with decreased mortality. The group presenting with fulminant myocarditis had a more severe course of disease and a higher in-hospital mortality (13.3% vs. 0%, p = 0.005). Conclusions The overall prognosis of patients with myocarditis is good – in terms of both survival and recovery without residual left ventricular dysfunction.

An attacker that gains access to a cryptocurrency user's private keys can perform any operation in her stead. Due to the decentralized nature of most cryptocurrencies, no entity can revert those operations. This is a central challenge for decentralized systems, illustrated by numerous high-profile heists. Vault contracts reduce this risk by introducing artificial delay on operations, allowing abortion by the contract owner during the delay. However, the theft of a key still renders the vault unusable and puts funds at risk. We introduce Phoenix, a novel contract architecture that allows the user to restore its security properties after key loss. Phoenix takes advantage of users' ability to store keys in easily-available but less secure storage (tier-two) as well as more secure storage that is harder to access (tierone). Unlike previous solutions, the user can restore Phoenix security after the theft of tier-two keys and does not lose funds despite losing keys in either tier. Phoenix also introduces a mechanism to reduce the damage an attacker can cause in case of a tier-one compromise. We formally specify Phoenix's required behavior and provide a prototype implementation of Phoenix as an Ethereum contract. Since such an implementation is highly sensitive and vulnerable to subtle bugs, we apply a formal verification tool to prove specific code properties and identify faults. We highlight a bug identified by the tool that could be exploited by an attacker to compromise Phoenix. After fixing the bug, the tool proved the low-level executable code's correctness.