注：本文来自@xiangganzi 推特，MarsBit整理如下：

数据可用性（DA）的定义，对现在大家理解还是存在很多模糊的地方。

简单来说DA就是，当区块生成者提出新区块时，如何确保区块里的所有数据都发布到了网络中？

这里可以分对象大家会更容易理解，A检测B发布的区块是否没有relesase所有数据?

主要分两种情况

轻节点检测全节点，L1 检测 L2。

更精确的说应该是B区块数据发布后（区块，batch已产生），A检测B是否release了所有数据？避免B作恶

轻节点检测全节点：

现有ETH方式常规方式是用户完全信任全节点，比如用小狐狸的用户就完全信任matemask钱包连接全节点RPC提供的数据（用户可以改全节点的RPC），并未实现轻节对全节点的检验。

celestia目前的实现方式是，如果全节点没有relesase所有数据，celestia的轻节点可以通过欺诈证明+数据可用性采样判断全节点是否实release了所有数据，未relesase所有数据的全节点将受到惩罚。

eth规划也有，但是还未实现，现在是calldata形式保存数据可用性，都是执行层全节点保存。

未来ETH要Proto-danksharding升级，但还是所有的共识层验证节点保存全部数据，再再下次danksharding升级才实现数据可用性抽象，实现轻节点验证。（验证方式可通过有效证明方式）

这里数据可用性是数据发布，不需要数据存储

L1 检测 L2 ：

检测opRollup的区块是否relesase所有数据: opRollup的VM执行一个区块(batch)生成新的状态根，然后opRollup把自己的交易数据上传至L1的数据可用性层，检测方式是任何用户可以通过自己运行VM，如得到的状态根与OP提供的不一致，就可在L1发起欺诈证明，如果一致就保证relesase了所有数据

检测validRollup的区块是否relesase所有数据：validRollup的VM执行一个区块(batch)生成有效证明，以及数据可用性（可以是交易数据，也可以是状态差），验证proof有效后，在验证数据可用性与其是否匹配，验证成功自然也就确认了validRollup的区块relesase了所有数据。

L1检测L2还有不同点，L1的安全性是高于L2的，所以L1要考虑到L2跑路的情况，即使L2跑路也得保障用户资产安全，L1的用户能根据链上存储的数据，还原出所有用户账户的状态，要消除这种风险就得做好数据存储。

对于L2而言，不仅需要L1做好数据可用，还需要支持数据存储功能(例如ETH归档节点，ETHStorage)