[buckie]

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

[nahollander]

Re: FV -- I admittedly have a surface level understanding of the entire subject matter. If you have any good primers and / or resources, I'd love to hear them.

re: Pact -- sounds super cool. I look forward to reading the white paper. Would be happy to scan the drafts if you'd be interested in sharing too

re: SEC -- just saw that too. I wouldn't say I totally disagree with the decision -- by Howie test standards, a governance token like DAO is functionally a security. Whether that jurisprudence will extend to grayer-area app coins and such is the real question.

At the moment, not planning on a token sale. Largely because of the concerns you've alluded to.

[buckie]

### 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.

[Crye]

Buckie, I'm in the process of reading your white paper on Kadena smart contracts, so it may answer this question. What is the purpose of a private block chain? Doesn't it become vulnerable due to available resource to out pace the block chain? Are there companies looking to secure intercompany transactions?

[buckie]

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).