I had read your article on happs’ architecture and their composability and this is a very exciting area for me as i firmly believe composability of apps are critical to network effects!
I had also just return from Ethereum Dev Con in Osaka where there was a lot of discussion in the aftermath on REAL PROBLEMS of composability of apps (which can lead to decline in network effects and fragmentation of liquidity etc) and complexity of communications across shards especially in sharded blockchains.
how “composable” are holochain happ? Can it be integrated seamlessly with other holochain happ with shared, open state? Is this possible when holochain ecosystem can be made up of possibily thousands or more of independent apps-specific DHT networks?
I know Holochain have a different design to sharded blockchains. Still, I like to know how similarly affected are holochain happs to problems face by sharded blockchains as mentioned above (and in title) and below reference links?
@pauldaoust Another reference article written by Vitalik Buterin on composability of ETH dapps in a sharded blockchain:
It does seems there will be complications especially involving transactions happening in 1 shard, and then needing to go to another shard and issues arising when 2nd transaction on another shard dont happen and what next needed to be done etc. Also issues of consistency when different transactions but inter-related happening on different shards at same time. And loss of attractiveness of on-chain arbitrage trading opportunities in a sharded environment. Developer of existing apps based on a single chain may need to re-write apps for sharded chains etc. The list of complication goes on…
So again, like to hear your perspective on any issues that beset sharded blockchain apps also possibly may apply to holochain apps (across different DHT network)?
@Sol I’m still getting a grasp of the issues, so please bear with me — it sounds like the Eth app developers’ concerns is that each Eth 2.0 shard is kind of a walled city in terms of validation — everything happening within the gates is considered safe, but everything coming through the gates from another city is suspect until some sort of mechanism proves its safety. That’s because contracts and the data they manipulate have to live in the same shard. Is that about right?
One thing I will say is that developers of existing apps based on a single chain or centralised database will definitely need to rewrite apps for Holochain it’s a very different world inside the DHT…
Hi @pauldaoust I think what you describe is more on the security and how shard ascertain the validity of incoming transactions from another shard which is another topic (and also a major issue in sharded blockchains) altogether.
It talks about complication arising when there are asynchronous communications between different smart contracts with different shards.
It talks about if there are various steps needed to happen in sequence or in parallel between different smart contracts in a “single atomic transaction” in a “single blockchain” - it is easier verify things that are suppose to happen, happen and if any steps did not happen, everything can be seamlessly unwound as the transaction reverse.
This can’t happen with smart contracts across shards. If any issue happens in say, step 2 of a cross shard communication/transaction, i understand that the process can’t be unwound automatically. There will be manual intervention needed and this causes friction and inconvenience (i think).
The issues get more complicated when it involved more smart contracts interactions with each smart contract living in different shards. Say 5 smart contracts interactions across 5 shards.
In a sharded blockchain, there are issues in both scenarios whether a app live in a single shard or an app lives in multiple shards.
I agree with you holochain apps totally different world/design architecture out there compared to sharded blockchain. Every app will always be their own independent DHT network and i think they will communicate with each other across the network via bridges and api calls.
What i am more concern is the composability and ability of holochain apps to interact/build on top of each other seamlessly without the complication that apps/developers will have to face in sharded blockchains as mentioned in all the links i posted so far.
I do hope that holochain doesnt face the same issue while retaining high composability as i believe it will help greatly with network effects and “compounded innovation”. Await your thoughts.
@pauldaoust Hi, managed to look through the links i post above to have a feel/context of the issues sharded blockchain faces? And how Holochain individual DHT networks may work/communicate differently and if possible dont face the same extent of composability issues? Perhaps, this can even be a new educational article on it owns by Holochain to educate the community especially this was a trending topic just 2 weeks back.
Ahhhhhh, I think i’m beginning to understand more. That video from Dieter Shirley helped me immensely (I love thought experiments). I would say that, rather than avoiding the complication of cross-shard, async, atomic finality for multi-step processes, Holochain manifests it even within one DHT, because each person’s source chain could be considered a separate shard.
I’m chewing on the implication of this… it seems that it will be important for most application designers. But I’m wondering also if we’ve already solved that with HoloFuel, because it’s expected to come to finality across two shards/source chains (Alice and Bob have to each execute a part of the transaction for it to work). The way it’s modelled in HoloFuel, it doesn’t seem all that complicated, and it makes me wonder if I’m missing something or if it really is that simple. Basically, the transaction isn’t ‘real’ until Alice and Bob have produced signed proof that it’s real. And if Alice and Bob are behaving themselves, neither of them will participate until they’ve checked for ‘uniqueness’ — that is, that their counterparty’s balance hasn’t already been spent. (This happens at the subconscious level.) Alice and Bob are the only ones with authority to engage in a transaction, and the validation rules check for that authority.
Probably most apps will want to settle on a ‘promise’ pattern, a notion of finality that everyone can agree on. To use the example of the train/hotel problem, where you don’t want to buy a train ticket until you’ve confirmed your hotel booking, and you don’t want to book a hotel room until you’ve confirmed your train ticket: because each transaction in a Holochain app happens in a multi-step process (proposal, promise, confirmation), you can back out any time you like. It’s not so much that the transactions are reversed if the terms of the contract aren’t satisfied; it’s more that they don’t complete so they aren’t considered valid yet.
One really nice thing about blockchains is that they offer the fiction of a single ordered timeline, that you can pause and act upon. This is wonderful for atomicity, but it’s not how the real world works, so you need an immense amount of effort to do it in a distributed way. Holochain doesn’t shy away from the fact that real time is a relativistic mess, which means that it consumes less resources but puts more responsibility on the app designer. But if my hunch is correct, this doesn’t have to be all that painful if app designers agree on this pattern of promises.
it’s a very different world inside the DHT…