improving the doc architecture and enriching some sections

[cowboyisaac]

Hi, here are some improvement suggestions:

1/ Protocol Architecture Risk renamed to Validation Protocol Risk, as that part mainly covers different validation systems.

2/ For the upgradable section (https://crosschainriskframework.github.io/framework/20categories/30implementation/protocol-implementation-risk/#upgradable), we can include the upgradable methodology of LayerZero (https://layerzero.gitbook.io/docs/faq/future-proof-architecture#perpetual-messaging) here. LayerZero supports upgrades by appending a new library into the registry and does not support in-place upgrades to cut out the silent modification surface. Applications can lock in the send and receive library to authenticate any messaging behaviors. I think this upgradable pattern is great for applications that do not want to assume any contract modification risks however good the governance might be.

3/ In the Protocol Architecture section, we can differentiate between
(a) a shared security model (e.g. wormhole guardian set)
(b) a configurable security model (e.g. LayerZero’s app owns the configuration)

4/ in the implementation risk section, we can consider adding
(a) precompiled library risk. E.g. Binance bridge hack (https://www.coinbase.com/blog/bsc-token-hub-compromise-investigation-and-analysis)
(b) client diversity, e.g. Binance consensus bug (https://www.binance.com/en/feed/post/212935)

[drinkcoffee]

Could you please create four separate PRs for each of these. Then each of the possibilities can be discussed on separately.

[drinkcoffee]

@ermyas thoughts?

[sambacha]

Hi, here are some improvement suggestions:

1/ Protocol Architecture Risk renamed to Validation Protocol Risk, as that part mainly covers different validation systems.

2/ For the upgradable section (crosschainriskframework.github.io/framework/20categories/30implementation/protocol-implementation-risk/#upgradable), we can include the upgradable methodology of LayerZero (layerzero.gitbook.io/docs/faq/future-proof-architecture#perpetual-messaging) here. LayerZero supports upgrades by appending a new library into the registry and does not support in-place upgrades to cut out the silent modification surface. Applications can lock in the send and receive library to authenticate any messaging behaviors. I think this upgradable pattern is great for applications that do not want to assume any contract modification risks however good the governance might be.

3/ In the Protocol Architecture section, we can differentiate between (a) a shared security model (e.g. wormhole guardian set) (b) a configurable security model (e.g. LayerZero’s app owns the configuration)

4/ in the implementation risk section, we can consider adding (a) precompiled library risk. E.g. Binance bridge hack (coinbase.com/blog/bsc-token-hub-compromise-investigation-and-analysis) (b) client diversity, e.g. Binance consensus bug (binance.com/en/feed/post/212935)

The LayerZero upgrade methodology has changed recently. Additionally, there are required upgrades to leverage potential changes to the EVM in the future, see this audit https://docs.google.com/document/d/1p-1VvOGwI5GHkwaGMzJYDL7Affofm6rVLa6cvnmoqGI/edit#heading=h.kp38zn44al54

https://dedaub.com/blog/ef-study-rlp-to-ssz this audit done for the proposed SSZ EIPs, they were able to measure the extent of the impact of these changes. The effects are observed on a handful of known projects, all of which are cross-chain bridges.