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