原文作者：Hoyt问题的由来：
为了实现链的容量扩展，Celestia承诺主权应用将只需下载与其有关的消息，而不用下载全部消息，但同时，不同应用的消息是打包在同一个区块里面的，以实现平等的安全性。那么，如何保证当某个应用的执行节点向Celestia的存储节点查询消息时，存储节点仅返回所有的相关消息，而且恶意存储节点无法隐藏特定消息呢。Celestia选择的方案是，将称为命名空间的应用标识符，插入到消息构成的默克尔树的节点信息中。这样做的好处是，可以处理存储节点隐藏全部相关消息的情况，可以定位被隐藏的消息。另外，无需大幅度修改默克尔树的生成逻辑，以确保存在一个节点，它的底层叶节点，包含且仅包含某个命名空间的全部消息，且能定位此节点。而只需要做三件相对简单的事情，就可以确保默克尔树的基本特性，不发生变化：首先，生成消息的默克尔树之前，先按命名空间将消息分组归并在一起，确保不同命名空间的消息没有穿插，且命名空间是排好序的。其次，修改生成默克尔树时使用的哈希函数，以便命名空间信息被包含进节点信息。检查默克尔树时，额外检查排序是否无误。生成带命名空间的默克尔树：
美国财长耶伦重申需要为稳定币制定一个全面的框架:5月12日消息，美国财长耶伦重申需要为稳定币制定一个全面的框架。（金十）[2022/5/12 3:11:42]
前面我们说了，跟通用的默克尔树逻辑相比，只有生成节点的哈希的函数不同。具体来说，就是在原哈希函数之上，又包裹了一层，使得节点哈希变成形如‘minNs|maxNs|原哈希’的形式，minNs和maxNs分别是此节点所有子节点中，最小和最大的命名空间。容易看出，对叶节点有minNs=maxNs，因为它只包含一条消息，只能有一个命名空间。默克尔树是二叉树，且我们已对消息做了排序，所以对非叶节点有minNs等于左子节点的minNs，maxNs等于右子节点的maxNs。另外，请注意原哈希函数会把子节点的整个哈希作为输入，也就是说命名空间也参与哈希计算，因此不能随意写，否则树根哈希会跟区块里的记录不一致，就很容易看出数据无效。下图是一个带命名空间的默克尔树的示意图：
YFX永续合约协议V1.0全面开源并推出Bug?Bounty计划:据官方最新消息，跨链去中心化衍生品交易平台YFX永续合约协议?v1.0现已在Github全面开源，并于2021年6月8日12:00-8月8日12:00（UTC）启动?Bug?Bounty计划，YFX将会积极给予发现者奖励支持，对被确认的漏洞提供最高50,000美金奖励。
YFX本次发布的是整个Github仓库级别的源码开源，涵盖ETH?layer2（xDai）、BSC、Heco、Tron四大公链，意味着全球区块链开发者可以随时跟踪开发进度，并一起参与完善代码。您可以在Github上查看YFX的开发进展。
YFX是一个基于?ETH?（layer2）、BSC、Heco、Tron、OKExChain、Polkadot?的跨链去中心化永续合约交易平台，提供?BTC、ETH?等资产高达?100?倍的永续合约交易服务。?YFX创新使用高流动性、低滑点的?QIC-AMM?做市商池交易机制，为用户提供了流畅、安全的交易体验。YFX已经成功支持?Layer2?的永续合约交易服务，它融合了永续合约交易员期望的?CeFi?式杠杆以及?DeFi?系统的?AMM?的流动性和简便性?，将成为?DeFi?领域基础性的金融设施。[2021/6/8 23:22:11]
以太坊2.0客户端Prysm推出v1.0.0版本全面支持ETH2.0主网启动:11月25日，以太坊2.0客户端执行团队Prysmatic Labs官方宣布推出Prysm v1.0.0。该版本全面支持12月1日以太坊2.0主网启动。官方提到，预计Prysm 1.0.x版本在以太坊2.0创世启动的12月1日20:00:23之前还会发布一个或多个补丁程序，以添加更多节点或做一些调整。此外，官方称将于下周推出另一个发行版本，并希望于以太坊2.0创世启动前或之后可以推出，并与Prysm v1.0.0兼容。[2020/11/25 22:02:11]
证明消息的完整性：
声音 | Cosmos开发团队发布上月“关键安全漏洞”的全面披露:据coindesk报道，Cosmos网络背后的开发团队Tendermint今天发布了有关上个月“关键安全漏洞”的全面披露。据报道，该漏洞使黑客能够绕过对网络上不当行为的某些特定处罚。该团队表示，在收到错误报告的前24小时内，其工具总共发现了22个事件。该漏洞现已在Cosmos网络上被完全修补，系统范围的升级已于5月31日在482,100区块高度被激活。[2019/6/18]
首先，需要证明返回的某条消息，确实是在消息树中，这个就是普通默克尔包含证明所作的事情。因此，当存储节点返回一条消息时，它同时返回此消息的默克尔包含证明。假定返回消息M0到Mn，那会同时返回对应的默克尔包含证明P0到Pn。我们需要说明，存储节点可以不返回某条消息，但无法对消息构成的默克尔树进行变动，因为那会导致树根哈希变化，数据失效。现在我们来看漏消息的情况，首先我们的消息是按命名空间归并在一起的，所以如果某个命名空间，在它所有消息的中间漏了消息，那任何一个默克尔证明都可以看出，消息不连续，就没必要进一步讨论了。我们看开头或者结尾漏消息的情况，两种情况类似，我们以开头为例。比如N.2的第一条消息M.2漏了，那它对应的P.0也不会发出来，那么这时候，从查询者的角度看，原来的P.1，现在是第一个证明，它反正就检查第一个证明。下图，我画出了P.0和P.1的具体内容，我们比较它们的差别，就发现M.2左侧的节点，命名空间都小于M.2的命名空间，而M.3左侧有一个节点H.4，它的maxNs是A.2等于M.3的命名空间N.2，这个A.2的来源，就是存储节点隐藏起来的M.2。这样一来，执行节点就发现异常了。那如果某个命名空间全部的消息都被隐藏呢。我们规定，当指定命名空间的消息不存在时，返回一个叶节点的默克尔证明，这个叶节点有minNs大于目标命名空间，但它左侧所有节点的maxNs都小于目标命名空间。那么，当存储节点隐藏了整个命名空间时，必然，根据具体返回的节点的位置，它或者左侧会出现一个maxNs大于等于目标命名空间的节点，或者右侧会出现一个minNs小于等于目标命名空间的情况。这样执行节点也能发现问题。综上所述，存储节点不可能隐藏消息而不被发现。
结语：本文复述了Celestia白皮书中，关于多应用场景下，对抗恶意存储节点的部分内容。现在Celestia测试网已经上线，但目前更多是展示了对轻节点的支持，以及对消息分组的可行性。白皮书里面，第三章、第四章都有提到更多关于应用主权或者分片的内容，比较偏概念，针对真实公网环境来说，具体是怎么实现的，目前还看得不是很清楚。而扩容问题，显然是整个区块链领域近期最关注的目标。所以，我们之后也会特别关注Celestia在支持独立应用方面的进展，究竟怎么跟L2或者说其它‘区块链模块’结合起来，做到实用的功能，并提高链上容量，我们将拭目以待。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。