Also hosted on github.
In part 1 of this series, I explained how transaction confirmation dialogs could look like. Instead of
they could show
This transaction calls setName("Chris"), which is documented
by the developers of the contract as:
Sets the stored name to "Chris".
This would be a tremendous win both with regards to usability and security.
In this part, we will see what the missing pieces in the ecosystem are to get to that point.
The Solidity compiler has been producing an artefact called “metadata” since version 0.4.7, which was released in December 2016.
Ethereum wallets ask the user before they sign any transaction. This is an important part of the security and trust framework of Ethereum. The problem is that the more often you confirm these dialogs, the less inclined you are to actually check the transaction. Do you know the pesky “TrustedVendor wants to install software on your computer.” dialogs? Exactly.
Furthermore, wallets usually ask you to confirm things like this:
Oh yeah, sure, good old 0xc47f! I know exactly what this is doing!
If you are lucky, some wallets might go an extra mile…
People keep asking about the status of our new low-level language IULIA and are often surprised when I tell them that it is already used in the Solidity compiler. Perhaps you have even used IULIA in the past without noticing. The reason is that IULIA shares a lot of code and structure with what was previously called “inline assembly”. For the compiler, the distinction between the two is often not even noticeable.
Original / updating version of this text: https://github.com/chriseth/notes/blob/gh-pages/articles/abi_iulia/abi_iulia.md
The release notes of some of the previous Solidity releases kept on mentioning the new ABI encoder, which will enable you to use structs and arbitrarily nested arrays in function arguments and return values. Still, when people ask whether it can be finally used now, I have to politely decline and say it is not yet finished. The main reason why it takes a little longer is that we re-implemented it from scratch in a new programming language. …
Underhanded coding contests are a good way to highlight shortcomings of a programming language. Solidity has a big advantage here over languages like C, because it can still be changed to some degree without breaking too many tools and programs. Because of that, in reaction to the Underhanded Solidity Contest (results) I would like to provide an analysis of some of the submissions and explain how we changed the language (or plan to change it) or at least explain which compiler warnings we introduced.
The plasma system defines a structure of interconnected blockchains arranged in a tree structure that promises scalable smart contracts. One of the key ideas there is that each of the blockchains regularly store their current block hash in their parent chain so that users can challenge potentially invalid child state transitions in the parent chain.
This model is secure not because of a difficult proof of work (the chains would use proof of stake or even a fixed validator set), but rather because users watch chains they have a stake in and thus will challenge invalid state transitions, potentially escalating…
Smart contract programming languages should be easy to understand and unambiguous. Usually, such languages are written in formal computer languages comprised of expressions, operators, functions and variables. While they are already quite abstract and hard to understand because of that, the fact that components of a smart contract can be referenced by name partly from anywhere in the program sometimes makes it almost impossible to see how different parts interact and fit together.
We propose a language that is situated at a level where even untrained people are able to grasp it. Babbage is a visual programming language that consists…
TrueBit has quietly gone through a major upgrade, and Jason Teutsch and I are pleased to finally announce the official TrueBit 1.0 protocol, available on our project webpage. TrueBit’s fond and familiar “dispute resolution layer” still lies at the core of TrueBit’s construction, but we’ve wrapped it up inside of a new “incentive layer.” This new layer should both properly reward Verifiers and, in turn, force Solvers to behave correctly. Practically speaking, smart contracts with TrueBit can execute C++ code without running up against Ethereum’s gas limit. …
A verification and storage solution for blockchains
University of Alabama-Birmingham
National University of Singapore
Supported by Wanxiang Blockchain Labs
Problem: the blockchain bottleneck
Ethereum’s incentive structure severely restricts the amount of computation work that smart contracts can accurately enforce. Each miner must not only verify but remember the state of every single smart contract on the blockchain. These redundant demands not only waste network resources but also limit the scope of potential smart contract applications. While honest Ethereum miners must verify every smart contract, only the miner who adds a new block containing…
One of the questions that often comes up in discussions about Ethereum is how to earn money with developing dapps, when anyone can just copy the contract code, remove or lower the fee and deploy it as their own. While this is a legitimate question, I don’t think that it is limited to blockchain code only. No technology prevents you in principle from removing the copy-protection code of the latest photo editing software and just selling your own copies.
Of course you can use law enforcement to prevent people from copying your code, but a much stronger force, network effects…