cdetrio

PL people often direct their "it should be functional and use strong typing" critique at the EVM rather than Solidity. Solidity is just one HLL (higher level language) that compiles to EVM bytecode.

A lot of the limitations of Solidity are due to constraints of the EVM, but the EVM is evolving. For instance, the next planned hard fork will enable the EVM to pass dynamically sized data (e.g. solidity arrays or strings) between call stacks. Previously arrays had to be fixed-size, so you'd have to define a fixed maximum size, then always return data of that size (usually a lot of empty elements). This feature, like many others, is somewhat challenging to design because every execution step of the EVM must be metered by a "gas fee"; the first version of the EVM kept it simple by only allowing return data to be a fixed size. See these issues for background https://github.com/ethereum/solidity/issues/164 https://github.com/ethereum/EIPs/pull/211

Also, the longer-term proposal is to adopt WebAssembly for EVM 2.0: https://github.com/ewasm/design. Then users can write contract code using any language with an llvm compiler (rust, ocaml, etc.).

The best tool for debugging is http://remix.ethereum.org/. It lets you step through the compiled EVM bytecode, while highlighting the solidity source mapping.

Most of those writes don't need to be serialized transactions. Other p2p data structures like CRDTs and torrents are sufficient for posting comments and uploading photos; see the decentralized social network Patchwork[1] (based on scuttlebutt[2]).

The blockchain itself will only be needed for certain types of transactions, for instance those around identity (e.g. name registration), and reputation/spam prevention (forum moderators).

1. https://github.com/ssbc/patchwork 2. https://github.com/dominictarr/scuttlebutt

Of course the best solution is for everybody to just coordinate. But coordination is hard, because there are strong incentives for individuals to defect (see also "Meditations on Moloch").

Making incremental improvements is the next best hope, and this one (giving cash) could turn out to be much more effective than previous state-of-the-art interventions (giving food, medicines, books, etc.). Additionally, enough incremental improvement might reach a tipping point where the poverty/coordination trap can be escaped, and the global equilibrium shifts.

The article links to Rodney Brooks, who mentioned this in a recent blog post http://rodneybrooks.com/unexpected-consequences-of-self-driv...:

> At least one manufacturer is afraid that human drivers will bully self driving cars operating with level two autonomy, so they are taking care that in their level 3 real world trials the cars look identical to conventional models, so that other drivers will not cut them off and take advantage of the heightened safety levels that lead to autonomous vehicle driving more cautiously.

Hmm, does this relate to the article from 6 days ago about the inability to find proton decay? https://news.ycombinator.com/item?id=13201065

The spec [http://gavwood.com/Paper.pdf] has been to revert on errors since day 1:

> Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. σ).

The Oct 4 commit just optimizes the way that reverts are implemented in go-ethereum (use a journal rather than deep copies).

Btw, small bone to pick with the Pact whitepaper[1]:

> EVM and Solidity have no support for atomic execution. Ethereum contracts simply abort on error, leaving developers with the impossible task of undoing previous writes and contract creates after any possible error condition.

EVM transactions are atomic; all state changes are reverted on aborts (out-of-gas errors and throws). Ethereum state changes are committed only after successful transaction execution, so developers never have to worry about writes from half-executed transactions.

1. http://kadena.io/docs/Kadena-PactWhitepaper-Oct2016.pdf

Last time I looked, you guys were developing Hopper, a contract language with a dependent type system. Why the pivot to Pact?

> can scale into the 1000's of nodes + maintain constant performance as it scales.

So transaction throughput stays at 5-15 tx/s and does not increase as you add nodes?

One of the ASF founders, Brian Behlendorf, was recently appointed E.D. at hyperledger.org (a project of the Linux Foundation). Perhaps Hyperledger is aiming to become the Apache of blockchains.

The ZeroMQ founder, Pieter Hintjens, describes Optimistic Merging (OM) vs. Pessimistic Merging (PM) and how he supports merging sub-optimal patches just to encourage contributors: https://hintjens.gitbooks.io/social-architecture/content/cha...

The pivot from rollingjubilee.org (which uses donations to buy discounted debt and abolish it) to debtcollective.org (where debtors can register and organize "debt strikes") was explained in a NYT column[1]:

> Until now, we have worked in the secondary debt market, using crowdfunded donations to buy portfolios of medical and educational debts for pennies on the dollar, just as debt collectors do. Only, instead of collecting on them, we abolish them, operating under the belief that people shouldn’t go into debt for getting sick or going to school. [.....] But this approach has its limits. Federal loans, for example, are guaranteed by the government, and debtors can be freed of them — via bankruptcy — only under exceedingly rare circumstances. That means they aren’t sold at steep discounts and remain out of our reach. What’s more, America’s mountain of student debt is too immense for the Jubilee to make a significant dent in it. Real change will require more organized actions like those taken by the Corinthian 15.

Its not surprising that they lost traction after the pivot. Buying discounted debt is a tactic which respects the logic of the market. Debt strikes go against the cultural norm of treating debt as a moral obligation.

1. http://www.nytimes.com/2015/02/28/opinion/a-strike-against-s...

People are working on formal verification of solidity code: https://forum.ethereum.org/discussion/3779/formal-verificati...

I read somewhere a conjecture that sleep for human brains is analogous to regularization schemes (such as dropout) for neural networks. Dropout helps the net avoid overfitting; nets that are overfitted have a difficult time distinguishing noise from signal. Sleep for mammals might serve a similar purpose, to help the brain avoid overfitting to noise (imagine if you had difficulty distinguishing dreams from reality).

The models in the "Frequent batch auctions as a market design response to HFT" paper by Budish et. al.; i linked the slides in another comment.

Since batch auctions use single-price clearing, market makers can post bids and asks without fear of being sniped (so its less risk, not more). And since you can't snipe, they have to compete on price rather than investing in faster connections, resulting in narrower spreads.

But faster (continuous-time) order processing results in wider bid/ask spreads; slower (discrete-time) batch processing results in narrower spreads. At least that's what the models show. Follow-up papers even analyze a multi-exchange model (competing continuous-time and discrete-time exchanges), and concluded that investors and retail traders would prefer the discrete-time exchange because it would have narrower spreads (i.e. lower transaction costs).

Yeah yeah, its called frequent batch auctions. obligatory mention in every hft discussion: http://faculty.chicagobooth.edu/eric.budish/research/HFT-Fre...

This is addressed in the linked issue.[1] Your criticism is the reason why (a subset of) WebAssembly is used, not LLVM IR.

1. https://github.com/ethereum/EIPs/issues/48#issuecomment-1690...

There is a proposal[1] to upgrade the current EVM to a WebAssembly based VM. Since webAssembly has a llvm backend, any language with a llvm compiler (which is most of them) could be used to write contract code.

1. https://github.com/ethereum/EIPs/issues/48

Simplish order types (limit/market, good till cancel, immediate or cancel, etc.) can only do so much. When you place a limit order on a continuous-time market, you'll pay exactly your limit price; but on a batch market you'll pay the clearing price (which may be less than your limit price).

The complicated types (hide-n-slide, NBBO pegs, and conditional pegs[1]) may help some players at the expense of others. The only players who wouldn't benefit from batch auctions (according to Budish et. al.) are latency arbitrageurs.

1. https://mechanicalmarkets.wordpress.com/2015/10/05/iex-peg-o...

Not sure what you mean by "quantized market" (discrete-time auction?). But the opening and closing sessions at the NYSE run at human timescales (twice per day), and most of the daily volume is traded at open and close iirc.

edit: "Across Wall Street, less trading is taking place at 3 p.m. or, in fact, most any time but the opening minutes and the final half hour." http://www.wsj.com/articles/traders-pile-in-at-the-close-143...

That's why market makers are also called scalpers, because they skim the $0.10 spread. But in return for paying the spread, what traders get is immediacy.

The problem is, how much immediacy do traders actually want? HFT provides immediacy in microseconds; its needed for continuous-time auctions because buyers sellers usually aren't in the market at the exact same microsecond interval (while the HFT is there at every interval).

Frequent Batch Auctions[1], where orders are matched in batches with single-price clearing (call auction style) - just like the opening and closing sessions of NYSE, but much more frequently with shorter periods of say 30 seconds, 1 second, or even 100ms per batch. Their models show that frequent batch auctions will reduce spreads even further (because it eliminates mechanical/latency arbitrage rents). In theory, retail traders should get even better prices (because the spreads will be smaller) if they are willing to give up microsecond immediacy for 1 second order matching.

http://faculty.chicagobooth.edu/eric.budish/research/HFT-Fre...

I've heard both arguments: (1) bitcoin script has no loops and so isnt turing complete; but (2) no loops is not a real limitation because the logic just be unrolled ahead of time and packed into a transaction.

Ethereum script is said to only be quasi-turing complete because although it has loops, execution is metered by gas fees (functionally equivalent to bitcoin tx size).

> Interestingly enough - there's even ways to make the answer to any computable problem the keys to unlock a Bitcoin payment

Sure, bitcoin script can in theory compute any computable problem (as can any turing machine). But it doesn't have native access to the data it needs, so pretty much any input you'd want to use needs to be put there by a trusted "oracle" (through a clever encoding into UTXO logic). For example, bitcoin script can't compare the amount of coins sent to two different bitcoin addresses, so you'd need to use oracles to do that [1]. In ethereum script it is trivial to do it on-chain (no oracles needed), since it was designed from the ground up for such use-cases (i.e. "smart contracts").

1. http://bitcoin.stackexchange.com/questions/36229/bitcoin-scr...

> SatoshiDice is a dapp that was built using bitcoin.

But SatoshiDice was not trustless; it was only provably-fair. By sending your dice bet to satoshidice, you were trusting them to actually pay you if you won instead of just keeping your money (though you didn't have to trust that they were using a fair die).

An on-chain dice contract is completely different, because there's no central operator that you have to trust to pay out the winnings.

The Coursera course "Economics of Money and Banking" is fantastic, and focuses on real-world mechanics rather than theory. You should be able to view archived lectures if there isn't an active course: https://www.coursera.org/course/money

Global clocks aren't required, as batch intervals on different exchanges don't need to be synchronized. Although the batch interval is a window of cross-exchange risk, the uniform-price clearing means it is still more efficient (in "volume-space"). Continuous auctions have really short risk windows (more efficient in "time-space"), but the discriminatory pay-as-bid price clearing means that all that risk is shouldered by everyone but the fastest traders (who are thus able to extract arbitrage rents from the slower traders).

The authors have apparently been giving presentations to various politicians/regulators, using an excellent set of slides: http://faculty.chicagobooth.edu/eric.budish/research/HFT-Fre...

> when a human trader places a market order, they will have a disadvantage equal to the volatility over 1 second.

No, there's no disadvantage for the human's 1-second-old stale order because batch auctions use uniform-price clearing (aka single-price clearing, all orders in a batch interval transact at the exact same clearing price).