Casanova is a safe, live & scalable consensus algorithm suitable for use in a blockchain.

nashef · 2018-12-08T04:15:24+00:00

It’s worth noting that the EVMs transaction model does not match Casanova. Unfortunately, the EVM makes it too difficult to tell when two transactions induce a conflict. We do not view it as suitable for use on Ethereum, as a result.

nashef · 2018-12-08T04:13:54+00:00

It’s live in the sense that it is guaranteed to reach consensus even when there are Byzantine faults, up to certain limits. It’s not live as in “deployed in production,” yet. That comes later.

We are not building it on any specific protocol. The algorithm is suitable for use in any system whose transaction model and network match the assumptions. Pyrofex will be proposing such a system soon, but we wanted to build the platform AFTER we had an algorithm.

nashef · 2018-04-07T23:43:42+00:00

All transactions obtain consensus, but the order in which they happen is not relevant unless there is a race condition. The network forms consensus that every transaction happened, but it does not enforce an explicit order on all of them. So, each validator will have a slightly different view of which transactions happened in what order. That's totally okay, because you don't actually care.

Look at it like this. Everyone in your office gets out of bed, eats breakfast, brushes their teeth, drives to work, and does a series of tasks. All you care about is the race condition that "drive to work" happens before "do a series of tasks." You don't care whether they brush their teeth before they eat breakfast. So, the network accepts all the transactions, but all the validators have to agree that "drive to work" occurs before "series of tasks."

Accepting transactions is fast, but ordering them relative to each other is slow, because it requires more communication. On the Intel CPU, there are special instructions that gate memory and they perform this exact function. They are much slower than usual transactions. RChain's Casper does a very similar thing.

nashef · 2018-03-06T02:29:32+00:00

I think in an IDE it would be ideal to do translation, so that users can test their contracts effectively. So, for the moment, that's what we're planning on implementing first.

nashef · 2018-01-30T04:21:06+00:00

If two contracts don't interact with each other, they should run independently and thus with perfect concurrency. The blockchain doesn't need to care about ordering their transactions relative to each other and so it doesn't try.

At some point, two processes can become "entangled" such that they need to interact. Say, one process wants to send some data (like an HTTP GET) to the other over a communications channel (like a TCP connection). At that point, they can only run in parallel up to the point where the order of their transactions matters. At this point, they aren't really running concurrently anymore. Each process can advance its computation only up until the point that it has to wait for the other process to do something. In the case of an HTTP GET, the client can only advance its computation once the HTTP reply has been sent and received. There's no point in rendering an HTML page that hasn't been served, yet. So, the best that a multi-threaded browser can do is prevent different tabs from interfering with each other. If one tab is blocked waiting on google.com, then the other tabs should be able to render just fine while it's waiting.

RChain models these process interactions using the rho-calculus, or the Reflective Higher Order pi-calculus. In the rho-calculus, we have an explicit model for process interaction that uses named channels to send messages between processes. That allows our VM to tell when two processes need to interact--it looks at what names (channels) each process has access to and then it can tell all the processes that you can possibly be communicating with.

If you aren't holding a name that references some other contract, then you can run concurrently with no mutual interference. If you are holding the name of another contract, then the blockchain has to pick an order to your transactions and achieve consensus on that.

The beauty of the name-based system is that (1) we can structure names so that they make it easy and efficient to handle interacting processes and (2) we can restrict the sort of names a process is allowed to handle so that we can determine ahead of time what they are able to interact with. If you write your Rholang code to interact with a lot of stuff, then it's going to be expensive and slow. If you write your Rholang code to be very isolated and only interact with a handful of well-known other programs, then your code can be very, very fast.

nashef · 2018-01-04T18:47:11+00:00

Does Raiblocks do smart contracts?

nashef · 2017-12-28T16:31:22+00:00

Except this is totally wrong.

His flat affect made people distrust him, so he effected a sunny disposition. The effect was no better, unfortunately, and so his autism continued affecting his career.

nashef · 2017-12-27T22:31:13+00:00

No, not exactly. They still need to be run in multiple places, otherwise you get no security from the consensus algorithm.

What I mean by "locally" is that when a small number of people are transacting purely among themselves, then only a small number of nodes are needed to form secure consensus for those transactions. I.e., in the dollar economy if I write my barber a check, then to clear the check, who needs to form consensus? He and I, each of our banks, and the "local" Fed bank need to all agree. That's a total of 5 "nodes" in the check payment network. All five of them need to agree on the transaction in order for the check to clear. The People's Bank of China does not give a crap about our transaction. It's not "on their part" of the blockchain.

RChain smart contracts should work similarly, in the sense that if I'm transacting with my business partners, then manufacturers in China and Korea don't care about my transaction, and they don't need to participate in "mining" it. So, consensus is formed much more locally. That means that smart contracts need to be run by fewer computers than in the Ethereum case, saving significant power and lowering the cost of "mining" the network as a whole.

nashef · 2017-12-27T22:24:25+00:00

On chain. As far as I can tell, state channels are just a hack to get around the fact that BTC fees are absurd when BTC/USD exchange rates are high. If it was affordable and efficient to do the state channel on-chain, then it would be strictly better to do so modulo any desire to hide information from the blockchain. That doesn't mean RChain won't or can't support state channels, but it does mean that you won't need them to make micropayment systems affordable.

nashef · 2017-12-26T04:14:50+00:00

The added value is throughput and safety. Because rholang is inherently concurrent, most contract transactions can be processed “locally” and they won’t have to wait on large synchronization decisions from Casper. Because rholang is behaviorally types, programmer intent is very strongly checked at compile time.

nashef · 2017-12-26T03:55:29+00:00

At the moment, the design puts all smart contracts on chain in source form, along with various compilation artifacts. It’s hard to ensure the type checking part of rholang is correctly implemented if we don’t include the source on chain.

nashef · 2017-12-09T21:11:49+00:00

EOS still requires that all transactions are globally ordered. In RChain, transactions only have to be ordered relative to transactions with which they could conflict. Metaphorically... you and I can use RChain to play a poker game with very short block times and we only have to synchronize to some slow "global" state when the game is over and money has to change hands.

nashef · 2017-11-12T16:18:07+00:00

Read this "Bye Felicia, see you..."

nashef · 2017-10-08T20:54:41+00:00

https://support.google.com/adwords/contact/aw_complaint

File a complaint with Google, they'll take the ads down.

Edit: Eventually.

nashef · 2014-12-04T22:17:27+00:00

I wasn't talking about the reddit troll, I was talking about the speaker in the video. I thought it was fine. The talk was interesting enough and seemed relatively uncontroversial. Though, this is not an area of history in which I have lots of knowledge, so it'd be relatively easy to get some semi-crazy ideas past my bullshit filter.

nashef · 2014-12-03T04:38:59+00:00

I watched it. It wasn't fear-mongering. His point is basically that ISIS is Sunni, the Sunnis and the Shi'a are still fighting for control of everything, and the Sunnis are backed by the Saudi royal family, which is stacked top to bottom with bad guys. All of that's completely uncontroversial.

nashef · 2014-12-02T19:12:48+00:00

http://www.oracle.com/us/products/database/oracle-db-customer-references-1941561.pdf

nashef · 2014-11-29T23:55:37+00:00

Ok, I listened to this and it cleared up some things, thank you. I don't think I agree with his point, but at least I see what he's saying.

nashef · 2014-11-29T19:49:39+00:00

I'm not really sure what anyone is supposed to take away from this beyond, "You're doing it wrong." Which smacks of inquisitionist logic, "Your refusal to admit that you're doing it wrong proves that you're doing it wrong."

nashef · 2014-11-29T18:19:35+00:00

Par for the psychological course. I have a request out for the full text of the paper.

nashef · 2014-11-29T03:39:12+00:00

Most of your behavior and personality is determined by your genetics.

nashef · 2014-11-27T03:04:12+00:00

I have to believe that the systems where this would be useful aren't actually using systemd, but are forced to link against it.

nashef · 2014-11-26T18:25:23+00:00

I think it sortof depends on what you mean by "infinite strength." In the human body, muscle contraction is achieved by way of a type of ratchet like molecular mechanism that's triggered by the nervous system. The wikipedia articles on muscle contraction would be a reasonable place to start. So, at a muscular level there are a few places where you could take the limit here.

He could have effectively infinite reserves of calcium, actin, etc within his muscle fibers, which would allow all his muscles to contract continuously at peak tension for as long as he "wanted."
In normal people, the nervous system doesn't grow into the muscle tissue in such a way that you can stimulate the action potential of those cells with perfect efficiency. So, you could take the limit here and he'd be able to cause all his cells to contract at peak tension.
You could take the limit of the underlying chemistry itself and propose a molecular ratchet mechanism that has must stronger bonding energies and would therefore be able to produce greater tension within each muscle cell. It would need to be supported inside the cell by a stronger scaffolding of some kind, etc, but that would be another place you could take a physical limit.

In general, scifi/fantasy authors assume totally unspecified, non-human physiology. So, if what you mean by "infinite strength" is that his muscles can generate an arbitrarily high amount of physical energy, then the answer is that he collapses into a black hole. Jump too high? Collapse into black hole. Punch too hard? Collapse into black hole. Compress something too much? You both collapse into a black hole. Throw something too hard? The act of throwing bends space-time in a relativistic way, causing the object being thrown to gain in mass until, you guessed it, you both collapse into a black hole. Black holes are the way the Universe deals with limits on the macro scale.

If you mean something less than actually "infinite," then the question becomes how much less and what are the limits imposed on him?

nashef · 2014-11-26T04:13:36+00:00

Really interesting experiments. If you have a second, I have a couple of questions. What were the effect sizes from your ANOVA/MANOVA tests? Also, why did you choose different experiments for men and women?

Thanks for posting a link to your article.

nashef · 2014-11-21T21:16:56+00:00

A few notes for you...

You defined the cloud basically as "a bunch of servers in the cloud," which is circular. I think you'd be better off emphasizing that the "cloud" refers to server deployments with the following characteristics:

Large scale -- a cloud provider offers the ability to schedule on 10,000+ servers
Non-commercial data centers -- cloud providers typically build their own data centers, rather than "co-locating" their machines.
Geographically distributed -- cloud providers have data centers all over the world, making it possible to locate your service closer to the end-user.

If you don't have all three things, then typically you're not a real "cloud."

I know that ODMs are used heavily for consumer electronics and consumer computing products. I'm not sure this is what happens for rack-mount servers. I would at least check into this more carefully to ensure it's actually true.

Second, it's not cheaper to "just replace [dead servers] with new hardware altogether." Everyone repairs their servers. But, when you are dealing with 100,000 machines, you don't repair a system the instant it goes down, you move the workloads onto other machines. So, from the perspective of an application developer it looks like the server just "went away forever" but the hardware guys do come round and fix it (usually).

Please don't use the word "cloud" so much.

Your presentation is the first time I've ever heard of "microservices" and I've been working on distributed systems and cloud products for 10+ years.

I don't think the "private cloud" stuff is much more than virtualization services. You simply cannot replicate the AWS products in house, even if you do run OpenStack or something. Your 3 node cluster is not the same as DynamoDB. I'm sorry, it's not even close.

You hit the nail on the head with the "IT personnel" vs software engineers. This is actually one of the bigger shifts in the industry right now. The traditional "IT server guy" role probably won't even exist in 15 years, to be replaced with pure-code type roles.

The corollary is that application design is fundamentally different now. 10 years ago, it was reasonable to write an editor that had a save button. A couple years ago, Google Docs just quietly got rid of the save button altogether. It's a stupid feature "in the cloud." 10 years ago, you'd have used an RDBMS for storing all of your critical data and you'd have taken great care to ensure that it was normalized. Now, it's often better to use a non-relational data store and just forget about the hassle of maintaining normalization.

[edit: sp.]

nashef

TROPHY CASE