RFC: Proof of Authority Urbit-Hosted PKI

[Ted Blackman]

Here's a first draft of a self-hosted PKI system designed around the specifics of Urbit's network structure, authored by me and Logan Allen.  Parts of it should be fleshed out further, and the basic protocol should be vetted for soundness, but we think this design could be the basis for a strong, permanent PKI solution.  Included is a proposed list of requirements for any Urbit PKI solution.

This is mostly a long-term idea, but using an Urbit-native proof-of-authority chain just for planets, leaving stars and galaxies on Ethereum, is a relatively incremental step toward a self-hosted PKI, which might be best considered as an alternative to rollups.

Let us know what you think.

https://gist.github.com/belisarius222/41998e569fe741ab0e1ffd98ec92b6f9

—

~rovnys-ricfer

https://urbit.org

[Jared Tobin]

On Fri, Oct 02, 2020 at 06:31:20PM +0000, Ted Blackman wrote:
> Here's a first draft of a self-hosted PKI system designed around the
> specifics of Urbit's network structure, authored by me and Logan Allen. 
> Parts of it should be fleshed out further, and the basic protocol should be
> vetted for soundness, but we think this design could be the basis for a
> strong, permanent PKI solution.  Included is a proposed list of requirements
> for any Urbit PKI solution.
>
> This is mostly a long-term idea, but using an Urbit-native proof-of-authority
> chain just for planets, leaving stars and galaxies on Ethereum, is a
> relatively incremental step toward a self-hosted PKI, which might be best
> considered as an alternative to rollups.

I think that PoA is naturally suited to an Urbit PKI and that this is a very
promising direction to explore. As the RFC points out, the crux is that we
already have a meaningful notion of authority baked-in via the galaxies anyway.

--
~nidsut-tomdun
https://urbit.org

[Basile Genève]

In the course of talking with ~rovnys about this, and also processing ~wicdev's (valid) objections to more centralized systems, I wrote the below. I think it's a decent framework for thinking about the tradeoffs and failure modes of a digital property ledger.

Note that the proposed solution should be taken more as a thought experiment as to the types of solutions that are available when you analyze Urbit in this way. The automation is mostly in the service of establishing a clear coordination point, NOT to automate forks.

https://gist.github.com/timlucmiptev/e6e338c195b0b4c268544be8d97a729f

[Sam Hart]

Hey all,

I had a call with Galen and Philip the other week to discuss what what a similar architecture using Tendermint and IBC might look like. Here are a few notes/links following that conversation:

Tendermint and Hotstuff are both pBFT variants and while they have minor trade-offs, frankly I think either choice would likely work given your use-case. For a sober comparison, see: https://decentralizedthoughts.github.io/2019-06-22-what-is-the-difference-between/

I asked a few of our engineers for block production estimates and given a validator set of 256, you'd probably end up with a block time on the order of 10 seconds. If <256 galaxies are participating this would be lower. There are some optimisations in the works that could also bring this number down.

If you were to implement consensus yourselves in hoon you'd likely need to create a number of jets to get down to an acceptable block time. There are maybe advantages to doing everything in hoon, but I can't think of many and it will be a longer road.

There are currently two implementations of Tendermint, one in Go that's been running in production since early 2019 and should hit 1.0 next year, the other is a Rust implementation that's still in development.

https://github.com/tendermint/tendermint

https://github.com/informalsystems/tendermint-rs

You can find a written spec and TLA+ formal specs at the following link: https://github.com/tendermint/spec

Tendermint is actually not a proof of stake protocol in itself, it has a notion of validator weight, but any staking or POA logic is meant to be implemented as part of a state machine server connected via a generic interface, the ABCI: https://github.com/tendermint/spec/tree/master/spec/abci

The ABCI server protocol has been implemented in a number of languages, for your purposes the rust and haskell packages may be of interest:

https://github.com/tendermint/rust-abci

https://github.com/f-o-a-m/kepler/tree/master/hs-abci-server

Notably, Galen also suggested the possibility of implementing an ABCI application in hoon, which I think could be an interesting approach.

And then there are a number of state machine frameworks that integrate ABCI server implementations, again there are rust and haskell frameworks:

https://github.com/nomic-io/orga

https://github.com/f-o-a-m/kepler

Similarly, the Cosmos SDK is a state machine framework written in Go, which is more of a batteries included solution: https://github.com/cosmos/cosmos-sdk

Finally, re cross-chain interop, this is really the main idea behind the Cosmos architecture, sovereign chains that have a clean way to pass assets as well as arbitrary messages between one another. 

You can do this with HTLCs, but this creates an unavoidable free option, which makes this method susceptible to grieving attacks. An elaboration of this problem in the context of the lightning network can be found here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html

The IBC protocol avoids this free option problem by performing light client validation of remote chains inside the local chain's state machine. Other than light client validation, IBC is modelled as closely to TCP-IP as possible, persistent connections, packets, etc. And like TCP-IP, the intention is to build application protocols on top. One I think is particularly interesting for Urbit's case is interchain accounts, which are essentially SSH tunnels that allow you to pass arbitrary messages to a remote chain and execute transactions remotely through a proxy account. This would allow you to interact with any chain that's implemented IBC or created a peg, so all Cosmos chains, but also Bitcoin, Ethereum, Polkadot, Celo, etc.

Here are some links to learn more about IBC:

overview paper: https://github.com/cosmos/ics/blob/master/papers/2020-05/build/paper.pdf

spec repo: https://github.com/cosmos/ics

rust implementation: https://github.com/informalsystems/ibc-rs

cosmos-sdk go implementation: https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc

I'll stop the brain dump there. Happy to answer any questions. Even if you don't end up going the route above, it would still be cool to find a way to do interop and I'm available if you have questions or need additional resources. Can also talk about potentially co-funding certain components.

Good luck with the migration and see you on Urbit :)

Sam