buckie

Does anyone know where the actual latest design for ETH 2.0 sharding is? Whitepaper/repo because w/o sharding you can't scale layer 1, and if you don't scale layer 1, you can't address layer 1 gas costs.

I've always been of the opinion that their sharding effort would fail, but I want to stay well informed. Sharding POS is very hard because the "trilemma" is correct for POS (kadena.io / explorer.chainweb.com being the example that the trilemma is solvable if you stick to POW).

Layer 2/zk-rollups will only help successful dapp devs lower their gas costs (see: DyDx). It doesn't relieve the pressure on layer 1 as other apps/patterns move in until a new equilibrium is reached.

I can't cite that example, I just have a friend whose parents are there tell me a story about how they were saying how pretty the snow flurries were and how he had to inform them about how ominous it was for there to be snow there. It's possible that they were referring to the frost that Sao Paolo got (which is still pretty crazy), and the videos of snow from further south.

One of my current concerns is that the demonization of climate scientists over the last 30 years has resulted in models that underestimate the timelines of how bad things get. Not an intentional conspiracy or anything, just a systemic natural response to the pressure of not wanting to be raked across the coals in the media as the "crazy".

As an example, the heat wave in the northwest of the USA and Canada this year was something I remember reading about as a problem to expect ~2050. Ditto for Siberia this year. Ditto for the snow in Sao Paolo.

I hope my concerns are misguided. I general though, short of a deus ex machina, I have no hope for the world doing anything about the climate emergency, even after it's obviously too late and even after the worlds seen a major city burned/wet bulbed/typhooned off the map.

I looked into it. It is next to impossible to get. It doesn't take a crazy amount of money to get it, but from what I've experienced it looks like it takes a ton of wealth + the right connections + Albany politics. And that was years ago, I assume it's worse now. Moreover, there's no SLA for responding to the applications... so there are likely 500-1000 applications sitting in a box some where in Albany.

Bitlicense isn't a disaster, but it's a huge problem if you're in the space that you really do need to be careful of crossing. Crypto has a meme factory but not a lobbying strategy, and even if it did it's up against two near immovable objects: old school finance lobbying and being an easy target/distraction in the press.

We should just be thankful that Bitlicense wasn't adopted elsewhere and give up on NYC as a hub for this stuff. Until crypto grows beyond finance AND legal combined (legal will lobby with finance if asked) in terms of who makes money in NYC -or- crypto allies itself with another major mover (maybe real estate), don't expect things to ever change for the better.

It's a shame really. NYC would be leading crypto if not for this law. But then again, NYC doesn't care because tech is probably the 5th or 6th largest revenue generator in the city and has few/no generation spanning connections to Albany.

but pointing to a factory that pollutes because you buy their products and want their product cheaply is equally inane

Agreed, but I'm not pointing at the factories. Consumers _can't_ lobby congress or control the media narrative. Factories don't lobby congress nor spin a media narrative designed to distract attention from those profiting off dumping the externalities of the business models onto the world.

I'm pointing at the corporations (the sum actions of their boards & C-suites taken as a single entity) that own the factories and reap the rewards. I'm pointing at the people that have effectively "won" capitalism and then took it way too far by changing the law and controlling the narrative to make sure they stay in power no matter the costs.

I hope there's some resolution that doesn't require a revolution, though I suspect we'll just do _nothing_... then it'll be a mega-clusterfuck the likes of which we can barely imagine... and maybe after the first 10M-100M deaths due to famine/heat/fires/storms we may figure out that we need to do something... and it'll be too late and/or that something will be another major war.

But before that western society gets to decide how to handle storms/crop failures/droughts driving the largest human mass-migration EVER (Central America => USA, Africa/Middle East => Europe) during a period when resources are constraining.

Welcome to climate change in the 21st century, where we'll be outraged/distracted by everything but how ~100 companies are responsible for 70% of global emissions[1]. Today we’ll be talking about evil terrorism enabling cryptocurrencies. Tomorrow we’ll be talking about individual choice and SUVs.

[1] https://www.theguardian.com/sustainable-business/2017/jul/10...

There is an example of directly scaling PoW that's been in prod for 1.5 years now: https://explorer.chainweb.com/mainnet

Instead of having X PH of PoW difficulty for a single blockchain, you have N parallel blockchains with ~X/N PH difficulty. Same energy needs, N*single chain performance. The coolest bit being that N can increase in an upgrade w/o needing to increase energy consumption, should the network gain traction and need more throughput. It upgraded from 10 to 20 chains last summer.

Other cool bit is that each chain runs a formally verifiable LISP (Pact)... I jokingly refer to Kadena as "a multithreaded LISP machine in the sky".

Disclaimer: I designed the Chainweb consensus algorithm

Not totally sure, but maybe this book? Fun read. https://en.wikipedia.org/wiki/The_First_Fifteen_Lives_of_Har...

These aren't street dealers. It's an organized, carefully designed, well-oiled machine. How does this machine work? How does it survive the loss of so many members?

Narconomics[1] has a pretty good discussion of the economics (including recruiting) of cartels.

[1] https://www.amazon.com/Narconomics-How-Run-Drug-Cartel/dp/16...

The problem with Proof of Work is that it is too inefficient and not that it consumes too much energy. If bitcoin could do 100k transactions per second globally, no one would be talking about Proof of Stake. We'd be talking about: how do we make mining green?

SWITH gpi was announced in 2015, piloted in 2016, and incorporated a blockchain PoC in 2017[1]. While only SWIFT knows if cryptocurrency was part of the conversation at the start, I'd be surprised if it didn't at least come up very early on.

In the context of how the politics of upgrading a bank's stack work, "driving" is the wrong word because in that context there are always people trying to drive "innovation". A better word is tailwind. Generally, banking tech is pretty crappy and good technologist can easily spot places where a big upgrade (aka "innovation") is warranted. The problem these people run into when lobbying for the upgrade is overcoming the hurdle of migration risk. The bigger the project, the bigger the hurdle. For JPM, I've heard this hurdle was summed up as _demonstrate a 1000x return on investment_.

Blockchain (via cryptocurrency) provides a tailwind to the people already trying to drive "innovation" in 2 ways -- it gives these people two additional angles:

1. As much as banks dislike spending money they hate losing market share. The risk blockchain poses helps in the lobbying for "innovation" without being a central point.

2. Higher ups can have the opportunity to be seen as "innovative in blockchain" by having the main "innovation" have a pet blockchain PoC on the side (similar to [1]) that's only kinda taken seriously. While the first bite at the apple (the upgrade) may not be enough this second bite (PR about them using blockchain) may satisfy them.

Does blockchain/cryptocurrency actually drive the discussion or make it into the final "innovation"? Probably not... today's gen 2 stacks just aren't good enough. Hopefully some gen 3's can change this in the next few years but that market still needs to be proven[2]. In the meantime, when dealing with a big bank's bureaucracy, every extra knot of tailwind helps.

[1] https://www.swift.com/news-events/press-releases/22-addition...

[2]: Disclosure: I was at JPM working on blockchain back when Gemini (now called Quorum) was first purposed and when Juno was the headline JPM blockchain project. I left to co-found one of these next-gen platforms: kadena.io

She is. I had the pleasure of working with her on in the distributed ledger tech working group (back when it was still the cryptocurrency working group) when she founded it in 2013. At the time, I was the lead eng for one of the SEC's quant groups and they needed a coder who understood the tech and didn't own any coin (exams/enf actions in crypto are tech-heavy). I raised my hand to be the founding tech lead specifically so I could be in the room to represent the "omg don't ban it, we don't know where this is going" position. Turned out that voice not needed at all.

The SEC has a well informed and nuanced view of crypto that underpins their restraint on the matter which, in no small part, is due to Ms. Szczepanik. If you're looking for an example of what happens when you don't have someone like her then look no further than NY. NY just jumped in and messed everything up with the Bitlicense.

Or you can just use graph theory to make PoW efficient & more secure[1][2]. Skip to page 11 of [1] for a quick visual summary.

[1] http://kadena.io/docs/chainweb.pdf

[2] https://www.youtube.com/watch?v=p1OFJOrgRWw

Is one of them Juno? https://github.com/kadena-io/juno. If so, I was lead eng on it so let me know if you have any questions.

FYI we're hiring haskell devs to work on our private consensus layer (based off of Juno), our public consensus protocol (http://kadena.io/docs/chainweb-v15.pdf) and our smart contract language https://github.com/kadena-io/pact + formal verification system. hiring+hn@kadena.io.

It's a fair read, the private blockchain market is underserved/misserved by the "widely" used platforms (IBM Fabric/R3 Corda). The thing that most everyone misses (including IBM and R3) is that the point of a private blockchain isn't the blockchain... it's smart contracts.

REST APIs + a DB can replace most "private blockchains as a time-stamper" usecases but here's the thing they can't do: replicate and trustlessly execute user logic. It's almost like you said _we're fixing SQL injection by making it irrelevant and making SQL into a full language_.

The blockchain itself just provides the trustless/high assurance substrate to then have trustless logic execution.

They also have different scaling tradeoffs as they scale really well (the graph can be arbitrarily wide as tx's can run in parallel) when most transactions are causally unrelated but hit bottlenecks with every "killer app" that gains traction (graph narrows as more and more transactions become causally related).

I'm not sure what domains see this problem crop up but I've seen it in quant finance strategy execution. Say you have 1k strats that you want to run in parallel but risk needs to bound the bank's per-equity positions globally. When the strats work on different subsets, DAG approaches aren't a problem, but when most of the strats trade APPL/IBM your once very wide (parallel execution) graph narrows significantly (becomes more sequential) as the strats need to check with risk w.r.t. AAPL/IBM sequentially.

NB: for this reason, causal approaches are pretty rare to see today (though it depends on the domain as high latency contexts don't really care).

Kadena | Software Engineer | REMOTE, ONSITE (Brooklyn, NY) | Full-Time $80k-$150k + Coin and/or Equity

Kadena is seeking Haskell engineers to join our team either in Brooklyn or remote. Kadena (http://kadena.io) is a tech-founded, post-revenue smart-contract blockchain startup founded in 2016 by Stuart Popejoy and Will Martino, two lead engineers from JP Morgan’s blockchain group. Kadena is poised to become the leading blockchain platform for businesses and enterprises by solving scalability and security concerns that impede widespread blockchain adoption. Our existing technology stack consists of our open-source smart contract language Pact and our private-chain protocol ScalableBFT, products that are already in use with Fortune-100 clients and coded entirely in Haskell. We firmly believe Haskell lends a decisive advantage through drastically enhanced productivity, excellent concurrency and parallelization support, unbeatable programming-language tooling, and sheer pleasure of coding. We’ve built a lot with just two devs, we can’t wait to see what you will add to our stack!

The ideal candidate will be able to work closely with a group but also drive projects independently. Developers are encouraged to interact at every level of product development. Initial focus is on building out our new public-chain protocol Chainweb and furthering our work in formal verification of Pact smart contracts; later projects will include operational pieces for the public platform like load balancers, monitoring, and messaging systems. Finally, partner integrations can lead to entirely new products integrating Pact smart contracts with bespoke systems. Public-chain projects are entirely open source (BSD3), and contributions to other projects are encouraged as well.

Exposure and expertise in any of the following areas is desirable:

- Network engineering

- Cryptography engineering

- Distributed Systems

- Programming language design (e.g. compilers, interpreters, development tools)

- Database Systems (RDBMS but also key-value systems)

- Software assurance/verification (Coq, SMTLIB2, QuickCheck, Jepsen, Coq, HOL)

- Industrial/production Haskell development

To apply please send a resume to hiring+hn@kadena.io.

I predict that 10 years from now normal relational databases have infrastructure for shared, authenticated and verified rows and columns

Agreed, though with the caveat that this is for transactional systems closer to the settlement/long term storage layers where the added assurance is useful. The performance hit for a traditional (linear) log is too large otherwise... though you can do a causally consistent version instead to reclaim some of the performance. But for more analytical workloads, I doubt it.

I'd actually go one step further and predict that in 3-7 years we'll start seeing early-stage startups, in fields completely unrelated to blockchains, using a smart contract enabled enterprise (private) blockchains for the majority of their backends... dropping most of the backend application layer (currently filled by django/rails/etc) in favor of a Vue/React <=JSON=> private blockchain arch.

The _reason_ such a shift might make sense is what you get in return:

- distributed w/ BFT (no _there's a problem with one of the nodes in the etc.d/consul cluster and its down/screwy_ problems)

- complete commoditization of high availability + disaster recovery

- good enough un-sharded write performance (a few 1000 tx's a sec) with unlimited read performance (writes are the expensive part)

- high-security env comes for free

That being said, the current state of smart contracts (specifically solidity but also plutus and tezos') makes this prediction laughable as, at the moment, writing/writing safe blockchain apps is quite difficult. However, if something _like_ Kadena's Pact (disclosure: am founder) finds traction it doesn't look too crazy.

Something like a procedural SQL for key-value DBs + capability-based auth + native REST support... which Pact effectively is when you strip away the blockchain context.

Given that the language is designed for safety and for technical executives/lawyers to be able to read if not write (similar to Excel's/SQL's usability by non-devs) it's stupid simple for a dev to learn. For example, a toy TodoMVC (Vue+Pact): https://github.com/kadena-io/pact-todomvc. Moreover, when you write a contract in Pact you get, for free, a REST API (pact types have native JSON reps) + an RDBMS representation. As if that weren't enough, it has a H-M type system (opt-in) + formal verification.

The only way this prediction can happen is if the smart contract language is far more effective at traditionally app-layer roles (e.g. django, rails). I'm not sure if it'll ever come to pass, but the combo of trivial to learn (and thus hire for) + abundant safety + formal verification could be enough to achieve it.

If we're listing smart contract languages, Pact is worth looking at. Check the demo contracts in the web editor for `Hello World`: kadena.io/try-pact

  ;; Simulate message data specifying an administrator keyset. 
  ;; In production use 'mockAdminKey' would be an ED25519 hex-encoded public key.
  (env-data { "admin-keyset": ["mockAdminKey"] })

  ;; Simulate that we've signed this transaction with the keyset.
  ;; In pact, signatures are pre-validated and represented in the
  ;; environment as a list of public keys.
  (env-keys ["mockAdminKey"])

  ;; Define the module.
  (module helloWorld 'admin-keyset
    "A smart contract to greet the world."
    (defun hello (name)
      "Do the hello-world dance"
      (format "Hello {}!" [name]))
  )

  ;; and say hello!
  (hello "world")

You should check out Kadena's FOSS Pact[1] smart contract language as well.

Though it currently only runs on our (disclosure: am co-founder) high-performance private blockchain stack we're prepping it for use on a public blockchain (the first presale opens in Sept). It's a pretty different approach from Ethereum/Tezos in that it doesn't use a VM and instead is a Turing incomplete interpreted language (still metered though). You can think of it like LISP (for computational logic) + SQL (for storage) + Bitcoin script (for auth/capabilites logic).

Pact, like Tezos, supports direct whole-program formal verification but, unlike Tezos, you don't have to write in a stack-based language nor learn Coq/SMT to be able to use the FV system. It has a doc-string annotation DSL that describes the code's intended properties[2] so that non-PhD's can leverage at least some of formal verificaiton's power.

Also, like Tezos, Pact supports on-chain governance but, unlike Tezos, this governance doesn't perform a hard-fork and is instead limited to specific contracts and their data. As a touch of background, Pact has a native notion of modules, which syntactically require their upgrade workflow (i.e. governance), and imports. The upgrade workflow function's only requirement is that it is pass/fail (so it can be single-sig/multi-sig/decentralized vote/hybrid).

When a transaction attempts to perform an admin-only operation on a given contract the governance function fires which, if passed, grants the transaction admin-rights (allowing for arbitrary upgrades/data migrations/change governance) over the code and data the governance function protects. We expect voting-based governance to revolve around voting on the hash of a proposed transaction ahead of time (via other functions in the contract with interact with tables that record the vote) where the actual governance function's role is to tally the votes (fail if no winner) and then check that the triggering transaction's hash matches the hash that won.

Take the DAO debacle as an example: community leaders notice the problem and propose an upgrade which fixes the bug + refunds the affected users out the exploiter's account in the cold wallet + removes the exploiter's account -> users check that the upgrade does what it's supposed to and vote yay-nay on the upgrade -> community leaders submit the upgrade once it's won the vote. No hard forks, no white-hats, same result.[3]

[1] http://kadena.io/try-pact

[2] https://youtu.be/Nw1glriQYP8?t=1060

[3]: Given that the exploiter could attempt to shuffle their accounts once the upgrade is publicized, I'd expect this class of response to be closer to: spot the problem -> elect a board of directors to take control of the contract (users vote on this upgrade, effectively granting the board god-powers over the contract+data) -> board locks the contract -> board fixes the contract + refunds the impacted accounts -> board returns the contract to decentralized control.

PS: if you want a fun problem to chew on w.r.t. strong correctness consider this -- if smart contract B imports A (both are on-chain) and A later upgrades what should happen to B? B's author couldn't have tested/verified B's logic with A's new version as it doesn't exist yet so it shouldn't auto-upgrade (what if A has introduced an exploit intentionally?). Moreover, A may be upgrading to add new features (so previous versions of A maybe should still work) or it may be upgrading to fix an exploit (so previous versions should be banned).

In Pact we solve this problem by inlining the code used from A into B at creation. Thus, A's upgrade cannot change B's logic and B's author is assured that the code they tested/ran formal verification on is the only logic that will run until they decide to upgrade B. There is, however, one caveat: any inlined code from A that is impure (touches A's data/tables) is inlined with the version hash of A. Everytime B tries to execute A's code (even before A is upgraded) this hash it checked against a whitelist associated with A's data. If the hash isn't found, the transaction fails. When A upgrades, the authors can choose to grandfather in previous versions hashes of A (in the case of new features that don't conflict) or not (in the case of exploit upgrades). Thus, A can ban impure code but not pure code (equations).

We jokingly refer to it as the "no-leftpad approach."

Preface: lead for Juno & ScalableBFT

First, some additional benchmarks:

* Juno (w/ hardcoded language): 500 tx/s

* TendermintBFT w/ EVM: 1k tx/s

* ScalableBFT w/ Pact: 8k tx/s

The thing about the high-performance private blockchains is that they are limited by the sequential smart contract execution performance. Juno ran an embedded "rough draft of a langauge" do it doesn't really count (not a full language, more like a complicated hardcoded counter). From TendermintBFT's docs, if memory serves, they say that if you hardcode a counter they hit +10k/s. For ScalabeBFT, it's it's ~14k/s. This is a minor difference, by the way, that isn't due to the consensus mechanism but more to the engineering of the system.

The reason for the non-hardcoded performance difference is that ScalableBFT runs Pact for smart contracts, which was designed to be a high performance interpreted language in part because of this bottleneck. Even if/when the EVM moves to WASM, the performance bump only impacts fat contracts by making them kill performance less. As in, if your 10k-step contract takes 200ms to execute and that drops to 2ms you can get 100x perf (not quite but it's fine)... but that only takes you from 5/s to 500/s and not to 1k/s or 8k/s.

The numbers above are for a simple coin transfer contract so the performance is mostly dependant on the read/write performance for keys in the DB. There's just not much contract level work to do when you're transferring coins between accounts so the WASM move won't bump things up much if any.

More broadly, I think that the article misses the point of private blockchains when it discusses them:

I would discourage you from blockchain consortia if your intention is to never use the public chain and if you don’t care about Ethereum. I’m going to put it bluntly: if you’re not looking at the public chain, you’re wasting your time. The benchmarking numbers paint a pretty obvious story — Quorum will never give you the speed of Kafka, especially since blockchains get less efficient as more participants join (because of that pesky “consensus” thing).

They serve a specific purpose: being a multi-administrative DB. Distributed DB systems (like Kafka, raft-based systems, etc.) can't robustly/safely serve that end.

I have a longer comment about it here: https://news.ycombinator.com/item?id=14853521

For skeptics like this, I've had success bringing up the history of paper money and point out how it took ~250yrs for the idea that money was the medium of exchange to take over (1705 with John Law to Nixon taking the US off the gold standard). Initially, paper money wasn't seen as "real" and we didn't even have an idea of what a reserve requirement was let alone how FDIC-like insurance would be REALLY useful for stability. I'm skeptical myself of if cryptocurrencies are really the "next version" of what is money, but a proper historical context lends credibility to taking them seriously.

Paper money initially was -- like cryptocurrencies are today -- inefficient, had interop problems and highly volatile. The main difference is the rate of experimentation/iteration today is so much faster and we have a complex understanding of economics already which we can use as a guide. Also, back then some of the experimentation was being run at national economy scales. Cryptocurrencies are great in that we can experiment with the idea without reaching/requiring a potentially economy-collapsing scale during the early iterations.

I doubt I'll live to see the if they turn out to be the "next version" vs an interesting experiment -- I can't imagine a wholly new definition of what is money taking root in under 2 generation.

I had a long discussion about this topic here: https://news.ycombinator.com/item?id=14807779

I think this is very inaccurate.

Perhaps, though keep in mind I did say that it is "[the odds that this code has a serious bug are] impossible to calculate accurately" and there's a reason for that. I'd argue that it wasn't an imprecise statement. Gavin was the father of solidity, put in the process at Parity, had an audit team, and the $200M multi-sig bug still got through. If the top-tier team and process failed, it's not imprecise to say that a more complex code base that didn't follow the best approach available likely has a bug. This is invariant on the phase of development.

Moreover, I was cautioning OP to be careful. One valid response to that is what he's already going to do (get an audit). This makes a bug less likely. The next phase would be a Bankor-style pilot+bounty. After that... well we just don't know.

But there are numerous smart contracts that have not been found to be vulnerable.

Sorry, but unexploited is not unexploitable. Many/most of these contracts are probably unexploitable, but the problem is that we can't be sure. To me, smart contract construction on the EVM/Solidity is closer to a "rolling your own crypto" grade problem, which is something that after years of massive exploits we've all agreed that you do not ever do it, vs building a webapp. Long term as tooling + approaches + standards + the language itself mature, it'll come closer to "backend programming at a hedge fund/bank" where it's doable but you need to be responsible.

The validators are known, so any risk of a 51% attack arising from some miner collusion in China does not apply.

That's just wrong. Dangerously so. Maybe I'm just missing something in his protocol spec and he didn't really mean mining...

I've discussed this attack vector in more depth here[1]. Even if you made the mining function signing the block with your sk it'd still be wrong. Even if you forced the sk holder to have that same sk protect something really valuable, it would still be wrong... just have a larger disincentivize.

The whole point of mining is that it's non-auditable (w.r.t. who is physically mining) -- the only real metric you get is the speed of success which you can always mask by not releasing a block immediately. That's why PoW is a cockroach of a consensus protocol.

In the "we roll a dice to see who gets to append to the ledger next" metaphor for consensus, deterministic and PoS both require you to know the number of sides the dice have before you roll them. In PoW, you don't figure out the number of sides until after.

[1] http://kadena.io/blog/MiningInPrivate.html

First, the pact paper needs to get updated to reflect the changes we made for the shift to public. For example, modules used to only be guarded by keysets (Pact doesn't have a notion of single-sig only constructs, anything using a sig supports multisig natively) and thus only support centralized upgrade governance mechanisms -- you don't need a decentralized vote in a private context -- so we generalized it to being a pass/fail (continue/error out) function that can do whatever it wants. e.g. you could have other contract functions record a weighted vote and have the governance function tally the vote (and run the upgrade only if it passes whatever threshold you set).

What is the purpose of a private block chain?

Great question -- I get this all the time. First off, public and private blockchains are despite their names different beasts serving different needs. Private blockchains are more a meeting of the best that public blockchains have to offer with the best of what databases have to offer, dropping the inefficient/not so great parts from each.

The tl;dr is that a private blockchain is really the realization of a multi-administrative DB. They serve the specific need -- that no other system can -- of allowing two companies that don't fully trust each other to share a multual store of information of value. This gets extended to include logic, and thus workflows, which is where it gets really useful.

There's a ton more to the business reasons for why they make sense (or will, the B2B sale cycle is slow and this tech is still quite new) but I'll leave that for later. Instead, let's walk through what you would have to do to make a similar, non-blockchain distributed DB like consul and try to adapt it to meet the aforementioned requirement: be able to share some of the nodes with people you don't trust. NB: I'm not talking about ScalabeBFT here; the logic is similar but does a lot to more to get high performance @ scale.

## The consensus layer

Consul uses raft, so we have multi-node quorums with strong consistency + an append only ledger parts covered already. However, you have two problems when you share it: #1 a bad node can take down/halt the cluster and #2 the leader can mutate the transactions it sees before replication. #2 is a problem because trustless, which we fix by having signed transactions so the leader can't touch them pre-replication. Moreover, we don't want the leader to replicate an out of date node with bad info, so we make the append only ledger a blockchain (either blocks or inc. hashes work the same.)

#1 is a bigger problem -- it's a problem of the consensus mechanism itself. Raft isn't BFT which is what you need to protect the cluster from a subset of bad nodes... so we make the consensus layer BFT, which is quite hard. The main practical reason we NEED to do this is because in a multi-admin context I can't ssh into your part of the cluster and kill a bad node... so BFT also protects me from your crap IT dept. There are other reasons for BFT too that are probably more important theoretically, but this is the most straightforward and practically important one because it will happen in production.

## Logic/DB/SQL layer (i.e. smart contracts)

To solve #2 above, we needed to sign messages. Now how do we interpret/check that the key used is one that we allow to be used? There needs to be some layer that is checking the sigs and applying the logic to the DB. Here too, we have a problem: there are multiple entity-level users on the DB that don't trust each other so how do we make a system that acts like a DB but also enforces fine grained auth schemes.

There's more to the story of how that question ends at "you need a smart contract language" but I don't want to detail every step. Instead we'll just assume it's right (ask if you want more details but tedious) and justify it with 2 practical reason: (1) you need to protect the data/flows that you put into the system behind some auth mechanism and (2) if you don't have a generalized way of capturing inputs, reading the current state, representing business logic/workflows, writing to storage, and enforcing authorization generally+finely then the private blockchain just isn't that useful. It'd be easier to just make a standardized API to get/push data to and a network of users. It's the safe, on-chain code exec that makes it different + really useful.

## private blockchain feature swaps (public vs db features)

Adding smart contracts + an append only crypto log are the main DB features that get dropped when making a private blockchain (vs procedural SQL and mutable tables).

Merkle trees/proofs are out: you don't need to support light clients as (a) this system isn't open to the public and (b) when you query the system you hit your local nodes which are by definition trusted oracles.

Native Traditional DB integration is in: one of the big issues for enterprise EVM users is getting the damn data out of the system (to pipe to their downstream systems) without having to run a query on the EVM. As you don't need Merkle/Patricia trees, you just have the smart contract exec layer incr hash it's tx log (tracks reads, writes, updates per tx deterministically) and use those to compare for data corruption event for a given node. This allows you to directly integrate the contract language's backend with a traditional DB (we just integrate with ODBC).

PoW/PoS are out, deterministic BFT is in: Both invalid in private contexts for different reasons. Both rely on incentivization via an on-chain coin, and break down without it. As there isn't a market to sell the coin, there's no value. Instead, you just need a fully auditable and deterministic BFT consensus. The good news is that they are WAY faster. Bad news is that they have scaling problems (though ScalableBFT should be able to have ~5k nodes before it starts to slow down).

NB: a prod system of 5k nodes can't just be thrown together and hit ScalableBFT's top numbers of 8k/s... we'd need so serious messaging solutions like those used in HF trading because there isn't a good open source UDP-like broadcast messaging system and bandwidth will be a problem. Scalable was designed with broadcast being needed as scale in mind (though it works fine up to 500 nodes so long as you have fat enough pipes). Also, we measure performance inclusive of the smart contract code itself. Pact is fast (~10-100x faster than EVM and getting faster for similar workloads) but if you have heavy logic on chain, it will impede performance. There's no magic bullet, besides dep-graph drawing for parallel exec which only helps non-sequential workloads, to this problem.

## Business reasons besides just a multi-admin use case

1. On-click real-time reg oversite: just put a node (read only probably) in their data center and give them the right keys. They now have full oversite into the entire chain.

2. Servicing semi standardized markets: there are a bunch of use cases where a unified market/settlement tech stack hasn't been built because the assets in that market, unlike say equities, are all just a little bit different. Think exotic OTC derivatives contracts -- the deal you did today is pretty close to the deal you did yesterday, but not close enough (some new parameters or something) that you don't bother to build a unified stack for them. Instead, each party does their own thing. Not the best example because the best ones are ones we're working on actively.

3. Lower-bound for how bad a system can ever be: This is the longest-term possible market strategy where the tl;dr is that a private blockchain gives you SO MUCH by default that it makes sense to use one internally (like consul) from the start. It fully upfronts a massive amount (disaster recovery, high availability, distributed, perfect replication, etc. are all commoditized) that if we make the part the user sees simple and safe enough (Pact is really easy to write + is formally verifiable) + useful enough (the contract is your REST API + DB integration) that it becomes an attractive substrate to write apps on from day one. The market, and tech, will need to mature a lot before this happens though. See the most over powered todoMVC here: https://github.com/kadena-io/pact-todomvc

Doesn't it become vulnerable due to available resource to out pace the block chain?

If you mean w.r.t. mining it would, but mining abjectly fails in private contexts http://kadena.io/blog/MiningInPrivate.html ; if you mean that it can't handle the throughput, then I'd say it's deterministic so you can shard out as needed (like we do in trading systems/everywhere today).

Are there companies looking to secure intercompany transactions?

Yes, but you can do that with an API already. It's more about the added utility of having something so robust that you can also represent workflows directly on (vs having to make a new endpoint and a new service behind it every time).

### FV Resources

These are few and far between. My paper on it is soup to nuts for how we do it in Pact which, while technical, should be somewhat approachable for most devs to grasp (I tried at least -- representing a program as equations is just an abstract concept).

Until it comes out, the best one I've found as an entry point was the approach they use in Cryptol: https://youtu.be/ruNFcH-KibY?t=897 . Cryptol, generally is a great project to look to for guidance. We're not going with the interactive approach. An EDSL in the docstrings is our approach so that you can pull a contract from the chain (pact is interpreted so the code on chain is the code that executes... well after it gets inlined and validated) and do the verification for yourself. Pact inlines at module creation/update time as a safety feature -- this way if a dep upgrades the code your contract runs doesn't change though the dep can revoke your code's right to access its tables/data until you update your contract. The "no leftpad" approach to deps.

All the imported code that's pure, however, still works. This way, when you are building a module, you know that the code you formally verified/tested against is the only code that will ever run (until you update it).

### Whitepapers

Thanks for the offer but I've already got enough people looking at them currently and we're keeping them confidential for now... a glaring stupid mistake would be embarrassing. Subscribe to the mailing list on kadena.io and you'll get updated with them the second they get released publically.

### SEC

FYI I used to work at the SEC and I was their tech lead when they formed the Cryptocurrency Steering Committee, which has been renamed to the Distributed Ledger Technology Working Group (DLTWG). I worked with Valarie (then the head of it, still is probably) on a few actions. This is the group did the investigation and put out the release.

Yep, no one is surprised by the take on the DAO and you're 100% right about the grayer-area of app coins. The key distinguisher will be, IMO, if the app-coin has real world use when it's sold + isn't supposed to return a profit as part of the app itself.

IMO, expecting to resell the app-coins for a profit will be fine in the same way that art can be bought/sold for a profit, and a profit can be expected when one purchases it, but also art can be hung (or rented out and shown for a profit). Everything else is strictly a security.

No need to forgive. You're not wrong nor naive. I'd pin the difference as one of personal risk tolerances. I have much less than you, that's all. Right now Solidity is the only choice of public smart contracts. All I meant before was that this is an impressive project and to be careful.

But, after all, a dark horse 20 year old college dropout spearheaded the development of Ethereum, and the technology now secures nearly 20B worth of value.

This is a really common trope in finance -- the trader/quant/manager/pm who thinks that he's god's gift to earth because he made so much money (and a system that made even more). I'm not saying that's what's going on in Ethereum, far from it, just that people who make a lot of money tend to think they are worth that amount of money (usually they are just fortunate) and that using monetary value as the sole justification for one's actions is (generally) wrong.

While I disagree that Eth is actually valued at $20B -- if you can't get even a fraction of the $20B out of the market then it's not worth $20B in value... I bet the buy side of the Eth market supports around $100M-$300M max -- that's neither here nor there.

The Ethereum ecosystem is, invariant on the value it represents, truly impressive and Vitalik's work is amazing especially given his experience level prior to it. I wouldn't say that the EVM is well designed in the slightest but the rest of the system is. It's closer to a 80's era CPU than a modern VM. I get why it looks like it does -- taking the bitcoin bytecode and extending it as little as needed -- but I disagree with the approach at a technical level. VM's are supposed to do more (e.g. handle dispatch and library loading) and to not support that means one must implement it in the language (like an ASM compiler does) which in a blockchain context consumes the limited gas you have.

I hold an optimistic view that, as formal verification techniques for smart contracts get fleshed out and easier to use

100% Agreed, though I don't think Solidity will have it anytime soon (3-5 year min for whole program verification that experts can use, I know some of the people working on it). The path the solidity FV people are following is a long, hard research path (close to what they did for the seL4 microkernel). Moreover, I know a ton about this because I built the first whole program formal verification system (compiler + DSL) for any smart contract language[1].

I built it for Pact, the language we[2] built to address the problems we saw with Ethereum's approach in enterprise contexts, that's FOSS but currently only available for on-chain use on our private platform. It wholly fixes the "immutable code" problem[3] via cryptocharters -- think of them as a module (smart contract) that have native support for both decentralized and centralized governance mechanisms for updating contracts and migrating the data they store. There's a bunch more stuff that Pact gets right, but that's what the papers are for describing.

Keep in mind that formal verification isn't the "end all be all" for program safety. While it massively advances the state of the art in that regard you need more than just FV because FV still requires human effort (just vastly less/safer than regular/auditing testing). It's just that FV is SO damn rare that most people, including myself until last year, (a) have no idea what it looks like and (b) have no idea what to use it for. People seem to think that an FV-capable language will solve all of their problems. No, it won't.

How many people going to become experts in SMT/Coq/Isabell just to write a safe smart contract? They, but Coq especially, make Haskell (which already scares people off) look like a cuddly puppy. What we'll need is a smart contract language that was designed to empower people to write safe code from the start + an FV system + a FV DSL that regular devs can use to leverage FV's power without having to become an expert in it. This is, unsurprisingly, exactly the feature set we have built for Pact. If you think I missed/should add a feature for empowering safe contracts I'm all ears (seriously, criticism/ideas are always welcome).

Wait a couple weeks and we'll have the public chain whitepaper(s) out (we're still refining the wording).

[1] https://youtu.be/Nw1glriQYP8?t=1072 -- my co-founder is presenting it

[2] http://kadena.io

[3]: "immutable code" gets you laughed out of the room in industry

Edit: this came out when I was writing the response... are you planning to sell tokens in the system? If so, again, be careful.

"SEC Issues Investigative Report Concluding DAO Tokens, a Digital Asset, Were Securities" https://www.sec.gov/news/press-release/2017-131

This project is simultaneously a great example of the democratizing effect of Ethereum while also being truly terrifying. A Stanford '17 grad with a few internships worth of industry experience is able to create and deploy a peer-to-peer loan infrastructure. This isn't meant to be demeaning in any way, I'm just remarking on how incredible of an accomplishment it is for both you and Ethereum that the previous sentence isn't fantasy.

Now, I'm someone with ~10yrs experience in finance/production engineering/regulation. That doesn't mean I'm right, just that I've been in the trenches for far longer and seen this type of domain from a number of sides over the course of many years. I need to at least mention that, well, this project is probably a bomb and you should be really careful with it. I, at least, wouldn't want to be the next DAO dev (e.g. project takes off quickly, unseen exploit exists, I lose some 10's of millions of other people's money) at mostly a personal (I'd feel guilty) and career trajectory level.

The Parity multi-sig bug occurred in a solidity shop that was founded by the father of the language itself. It got past a serious audit and had the best eng process known (for solidity) enforced. The odds that your code -- currently unaudited correct? -- doesn't have an exploit are, while impossible to accurately calculate, quite remote. Even an audit, as shown by Parity, is no guarantee. And while yes, we're all human so there is always the chance for a bug, your system could be the next ITO market and thus could gain a huge amount of attention (from both regular folks, regulators, and hackers).

I'm not saying you shouldn't do it (I wouldn't but you do you) or that you must have more exp to do it. I'm just recommending to be careful. Have fun and good luck!

That the auditing missed the bug doesn't prove...

Honest question, what would be required in your opinion for before we start considering if the tool is at fault? I ask because, if you're of the opinion that it's never the tools fault then I'll never be able to justify my point of view. Which is fine, we can disagree. I'm all for massive experimentation in this area and thus need people who disagree with me to do research down the other lines.

Also, it's not that I think it will always be practically impossible just that currently (and for the next several years at the very least) it is. We'd need way better tooling and the type of tooling needed is incredibly advanced stuff. We're not talking about a build system here, we're talking about formal verification which is one of the most advanced tools you can build. I can only think of one tool that can formally verify user generated code (cryptol) and even then it's only for a small subset of C/Java that applies to crypto work.

It's not that you can't write safe solidity contracts today but that IMO an element of luck is required. You need to get the right auditors, have them do a good enough job, implement the logic a certain way instead of another and thus avoid a bug no one has thought about before, etc... When people's money is on the line, needing luck is terrifying.

nothing is stopping you from porting your formally verifiable language to Ethereum

I wish this were true but it isn't. We spent months trying to see if there was a way that it would work because we would have preferred this approach. The EVM itself is stopping us (as well as the shape of the Eth blockchain but we could probably have worked around that problem). Pact is interpreted, so while we could make an EVM version technically it's practically unworkable -- there's nowhere near enough gas to run the interpreter. We couldn't compile directly to EVM either as the EVM just doesn't do enough[1] for you. It's closer to a 1980's era CPU ASM than a modern VM (like the JVM). Moreover, the Pact runtime does a lot of things for you (as a safety feature) that the EVM just doesn't have a notion of. Even then, while all of the Pact-compiled-to-EVM code would work and be safe, we couldn't protect it that code from EVM code that doesn't play by Pact's rules. Moreover, supporting all the extra things that Pact does for you would make it, again, run out of gas on EVM.

This discussion is very similar to putting Ed25519 on the EVM. While you can technically implement it in EVM, it's just too gas-heavy. It's best to extend the EVM itself to do more.

That's the thing about having the EVM be Turing-complete, it makes people think that "it can do anything and thus abstracts over the problem thus solving it." This is technically true but not practically true -- all you are doing is punting a huge number problems/required features (like dispatch and module loading) down the road for the language to figure out. In a gas-metered context, every feature the language adds because the EVM lacks it costs gas and thus makes a number of features impossible in practice.

In fact there is already a project underway to create a verifiable programming language for the EVM.

Mind linking me to it? I collect references to smart contract languages at this point and haven't heard of this one. I know the people working on the EVM + solidity formal verification project personally (well some of them at least) and it's still years away.

[1]: Great technical discussion about EVM here -- https://news.ycombinator.com/item?id=14689792

Why bad timing? This is really just an example that while safe smart contracts are technically possible using Solidity/EVM, it's practically impossible. "One of the best Solidity devs" just failed to write a safe contract to the tune of a $30M exploit. Given that, what chance does anyone else have?

At some point, it's time to blame the tool and not the user. Moreover, it's not like people didn't see this coming, myself included[1]. I mean, who really thought that basically taking JavaScript and swapping out the DOM for a bank account wasn't going to end badly? But then again, maybe I've spent too much time at in the SEC/finance where "move fast and break things" engineering gets you shown the door quite quickly. That mantra's fine for a number of domains but finance isn't one of them as one bug can bankrupt the company (see: knight capital).

It really just underlines the need for a safer/better approach. Formal Verification has to be part of that story. A language that was designed with safety in mind has to be another part.

Also, not an academic (yet at least). Cofounder here: http://kadena.io

[1] https://goldsilverbitcoin.com/jp-morgans-blockchain-research...