Sei中文在Sei上质押：深入探讨权益证明 (PoS)
Subscribe在不断变化的数字资产世界中，“质押”已经成为参与加密生态系统运转的常见术语。但在Sei这条最快新公链的背景下，质押意味着什么呢？什么是质押？质押可以被视为确保“权益证明”区块链（例如Sei）运行的一种方式。这种贡献有助于维护网络的完整性和功能性。Sei上的质押是如何运作的？每个区块链都需要一种机制来确保交易和余额的准确性和公平性，从而创建一个“无需信任”的去中心化系统——这被称为“共识”。在Sei上，与其他权益证明区块链一样，验证者扮演着关键角色。他们帮助验证和保护新交易，维护系统的完整性。作为回报，网络奖励Sei代币承认他们的贡献，以确保系统保持值得信赖且在经济上可行的运作方式。质押奖励作为Sei去中心化权益证明机制的一部分，世界各地的验证者负责维护Sei区块链的安全性和准确性。验证者运行称为全节点的程序，使他们能够验证在Sei网络上进行的每笔交易。验证者提出区块，对其有效性进行投票，并将每个新区块添加到链上。 用户可以将他们的Sei质押给验证者，并获得质押奖励，而验证者本身可以设置一项佣金来补偿他们在其中起到的重要角色。更高的佣金意味着验证者会获得更大比例的...
Sei中文Sei区块链走向碳中和
Subscribe作为创新区块链基础设施的建设者，Sei Labs和Sei Foundation团队理解人们对这种技术可持续性的担忧，以及降低环境影响的重要性。 这就是为什么Sei正在采取超越其他行业参与者的措施，确保链消耗的能源完全来自可再生能源。这使Sei成为一条在运行中碳中和的区块链。 为了做到这一点，Sei Labs将利用一种全新的RWA原语：由Jasmine发行的Token化可再生能源证书。 减少区块链运营的碳足迹涉及衡量和努力减少链运营中增加排放到大气中的二氧化碳。 Sei Labs将通过以下方式实现这一点：通过采用“股权证明”共识机制，Sei区块链的能源消耗将比比特币等“工作证明”区块链少99.9%。确保Sei使用的能源来自可再生能源，如太阳能和风力发电，通过区块链发行可再生能源证书。两个想法中的第一个并不新颖 - 绝大多数现代区块链都运行在股权证明共识上，不需要大型的“挖矿设备”设施，这些设施有大量耗能的GPU排成行列。在Sei上，一个高端家用PC就能完成比特币设施的同等角色。 第二个想法是新颖的，利用尖端的RWA技术。Sei将通过Jasmine Energy发行...
Sei中文Reflexivity Research：Sei研究报告
Subscribe摘要 / 简短总结Sei是近日备受关注的另类L1区块链，专注于交易，具备独特的功能，如并行交易处理、本地订单匹配引擎和双涡轮共识机制。通过与从基础设施到DeFi等各个领域的合作伙伴关系，Sei正在努力构建一个极为充实的生态系统，拥有一整套应用程序和用例，这些在主网上线的第一天就准备就绪。Sei生态基金中已积累了超过1.2亿美元，团队和各种战略合作伙伴正在积极寻找各种有前途的应用程序，在未来几个月甚至更长时间内部署在Sei上。原文：Sei Network Overview, Reflexivity Research 翻译：Sei中文查看Sei及其独特之处回顾一下，2020年和2021年似乎是另类L1（通常称为“以太坊杀手”或简称为另类L1）的时代。以太坊上每天活跃地址的急剧增长导致了Solana、Avalanche和Fantom等另类L1的同样急剧增长。由于以太坊上的交易成本飙升至100美元甚至更高，即使是像简单的Uniswap交易或NFT铸造这样的常规操作，普通用户也很快就无法承受了。除了高昂的交易成本，新用户的涌入导致网络越来越拥挤，失败的交易过于普遍，极大地...
专为交易设计的最快L1，为交易类应用（DeFi/NFT/GameFi/SocialFi）提供最佳基础设施。Sei是首个基于订单簿的L1，应用Cosmos SDK与Tendermint Core技术。 Sei官方中文推特🔗twitter.com/Sei_Chinese
Sei中文在Sei上质押：深入探讨权益证明 (PoS)
Subscribe在不断变化的数字资产世界中，“质押”已经成为参与加密生态系统运转的常见术语。但在Sei这条最快新公链的背景下，质押意味着什么呢？什么是质押？质押可以被视为确保“权益证明”区块链（例如Sei）运行的一种方式。这种贡献有助于维护网络的完整性和功能性。Sei上的质押是如何运作的？每个区块链都需要一种机制来确保交易和余额的准确性和公平性，从而创建一个“无需信任”的去中心化系统——这被称为“共识”。在Sei上，与其他权益证明区块链一样，验证者扮演着关键角色。他们帮助验证和保护新交易，维护系统的完整性。作为回报，网络奖励Sei代币承认他们的贡献，以确保系统保持值得信赖且在经济上可行的运作方式。质押奖励作为Sei去中心化权益证明机制的一部分，世界各地的验证者负责维护Sei区块链的安全性和准确性。验证者运行称为全节点的程序，使他们能够验证在Sei网络上进行的每笔交易。验证者提出区块，对其有效性进行投票，并将每个新区块添加到链上。 用户可以将他们的Sei质押给验证者，并获得质押奖励，而验证者本身可以设置一项佣金来补偿他们在其中起到的重要角色。更高的佣金意味着验证者会获得更大比例的...
Sei中文Sei区块链走向碳中和
Subscribe作为创新区块链基础设施的建设者，Sei Labs和Sei Foundation团队理解人们对这种技术可持续性的担忧，以及降低环境影响的重要性。 这就是为什么Sei正在采取超越其他行业参与者的措施，确保链消耗的能源完全来自可再生能源。这使Sei成为一条在运行中碳中和的区块链。 为了做到这一点，Sei Labs将利用一种全新的RWA原语：由Jasmine发行的Token化可再生能源证书。 减少区块链运营的碳足迹涉及衡量和努力减少链运营中增加排放到大气中的二氧化碳。 Sei Labs将通过以下方式实现这一点：通过采用“股权证明”共识机制，Sei区块链的能源消耗将比比特币等“工作证明”区块链少99.9%。确保Sei使用的能源来自可再生能源，如太阳能和风力发电，通过区块链发行可再生能源证书。两个想法中的第一个并不新颖 - 绝大多数现代区块链都运行在股权证明共识上，不需要大型的“挖矿设备”设施，这些设施有大量耗能的GPU排成行列。在Sei上，一个高端家用PC就能完成比特币设施的同等角色。 第二个想法是新颖的，利用尖端的RWA技术。Sei将通过Jasmine Energy发行...
Sei中文Reflexivity Research：Sei研究报告
Subscribe摘要 / 简短总结Sei是近日备受关注的另类L1区块链，专注于交易，具备独特的功能，如并行交易处理、本地订单匹配引擎和双涡轮共识机制。通过与从基础设施到DeFi等各个领域的合作伙伴关系，Sei正在努力构建一个极为充实的生态系统，拥有一整套应用程序和用例，这些在主网上线的第一天就准备就绪。Sei生态基金中已积累了超过1.2亿美元，团队和各种战略合作伙伴正在积极寻找各种有前途的应用程序，在未来几个月甚至更长时间内部署在Sei上。原文：Sei Network Overview, Reflexivity Research 翻译：Sei中文查看Sei及其独特之处回顾一下，2020年和2021年似乎是另类L1（通常称为“以太坊杀手”或简称为另类L1）的时代。以太坊上每天活跃地址的急剧增长导致了Solana、Avalanche和Fantom等另类L1的同样急剧增长。由于以太坊上的交易成本飙升至100美元甚至更高，即使是像简单的Uniswap交易或NFT铸造这样的常规操作，普通用户也很快就无法承受了。除了高昂的交易成本，新用户的涌入导致网络越来越拥挤，失败的交易过于普遍，极大地...
Share Dialog
Share Dialog
专为交易设计的最快L1，为交易类应用（DeFi/NFT/GameFi/SocialFi）提供最佳基础设施。Sei是首个基于订单簿的L1，应用Cosmos SDK与Tendermint Core技术。 Sei官方中文推特🔗twitter.com/Sei_Chinese
Subscribe to Sei中文
Subscribe to Sei中文
>100 subscribers
>100 subscribers
Inter-Blockchain Communication (IBC) 协议是一个开创性的框架，旨在促进独立区块链之间的安全无缝通信，使它们能够相互传输代币和数据。IBC是一项复杂而具有挑战性的技术。
在过去的几个月里，Sei实验室工程团队观察到在几个第三方服务商上，Sei区块链上OSMO代币的总流入和流出存在差异。Sei实验室团队经过调查和分析确定了问题的可能原因：这些不匹配是由第三方服务商索引和解释数据的方式导致的。值得注意的是，这并不是由于任何链级问题。
本博文将详细介绍如何发现、调查此问题，并提出两种潜在解决方案。
注：在调查后，Flipside Crypto团队被告知了此问题，并迅速修复，我们对他们的合作和支持表示感谢。
问题最初是通过Flipside报告暴露的，该报告似乎显示Sei区块链上OSMO的总流入自启动第二天以来似乎总比总流出要小。这是没有道理的 - 要进行交易流出，必须先放入代币，因此总流入必须等于或大于总流出。唯一可能发生这种情况的合理解释是Sei和Osmosis两侧IBC逻辑存在错误。
Sei实验室工程团队在Mintscan上查找了类似但不同的结果。差异如下：
为了确定这些不一致性的起源，Sei实验室工程师重新索引了Sei主网启动后的前几天数据。他们的研究证实了流入和流出总量是一致的：
(Net_Inflow_18520000_to_19300000 - Net_Outflow_18520000_to_19300000) + Bank Supply of IBC Uosmo on height 18520000 = total supply of uosmo at height 19300000.
In this equation: Net_Inflow_18520000_to_19300000 = 289607886926903
Net_Outflow_18520000_to_19300000 = 288034713858306
Bank Supply of IBC Uosmo on height 18520000 = 20685000
Bank supply of uosmo at height 19300000 = 1573193753597
Sei实验室工程师现在已经发现了两个不同的第三方数据提供商看似不一致的流入和流出总量问题，并进行了根本原因分析。
在确认链上总量确实如预期般正确匹配后，关注点转向了第三方服务商如何对IBC数据进行索引。Flipside在GitHub上开源了他们的数据模型，因此这是一个好的起点。
Flipside的数据模型通过观察区块链上的 'ibc_transfer' 活动计算IBC流出，通过观察 'write_acknowledgement' 消息和 'packet_data' 属性计算IBC流入。
让我们看一下成功的IBC转账是如何进行的：
在链A上创建数据包（源链）：
a. 链A上的用户启动向链B的代币转账。
b. 这个操作导致在链A上创建一个表示代币转账的IBC数据包。链A上的代币被保存在IBC托管账户中，确保它们不会被双重花费。需要注意的是，这里的每个通道对应一个唯一的托管账户，例如osmo<>sei通道的托管账户与axelar<>sei通道的托管账户不同。
c. 交易＃1：在链A上进行一次交易以启动转账。
将数据包中继到链B：
a. 一个中继者注意到链A上的新数据包，并提交了一笔交易到链B作为中继数据包。
b. 交易＃2：在链B上进行一次交易以接收数据包。
在链B上处理数据包（目标链）：
a. 链B处理数据包，为预期的接收方在链B上铸造相应的代币，然后生成确认。
将确认中继到链A：
a. 一个中继者注意到链B上的确认，并提交了一笔交易到链A来中继这个确认。
b. 交易＃3：在链A上进行一次交易以处理确认。
因此，如果所有的IBC转账消息都被记录，而所有的交易都按照上述方式进行，总数就会匹配，对吧？理论上是的。
实际上，有一个问题：超时。一些IBC转账创建时带有超时参数，可以指定为块高度、时间戳，有时两者都有。在此时间或块高度之后，IBC数据包将被视为超时……那么接下来会发生什么？
如果一个中继者试图将一个已超时的IBC数据包中继到链B的IBC模块，该模块将返回一个超时错误。中继者通知链A上的发送模块数据包已超时（使用TimeoutPacket）。原本要转账的代币被发送回转账发起者，IBC转账失败。
现在您已经看到了IBC转账交易的生命周期，并了解了由于超时而导致这些交易有时会失败的原因，您就能理解在数据中观察到的IBC流入/流出差异的可能原因。Sei Labs工程团队回顾了Sei区块链启动后几天的交易数据。的确有许多流出IBC转账超时的情况。
第三方数据索引器将每个ibc_transfer事件都计入IBC流出，即使该转账后来超时 - 即使转账交易在源链上最初成功，仍然有可能在中继期间超时。因此，这些数据提供商计算的总IBC流出既代表了成功的IBC转账，也代表了那些已经超时的转账。这就是为什么IBC流出大于流入的原因。
与其处理IBC转账事件以获取流入/流出金额，Sei Labs工程团队建议统计从IBC模块账户中转出或转入的所有非本地代币的总量，因为这考虑了上述所有情况（即转入、转出以及超时后的退款）。
他们提供了以下代码片段，以实现这种方法来解析金额：
// IBC Transactions: Check tx event for event type 'transfer' between ibc-transfer module account and sei account
// Example: {"type":"transfer","attributes":
// [{"key":"recipient","value":"sei1z3g0ccd0gpe6m4afjjmtxka269yyrymhwwvf3x"},
// {"key":"sender","value":"sei1yl6hdjhmkf37639730gffanpzndzdpmhrn8l3z"},
// {"key":"amount","value":"7898600ibc/2CC0B1B7A981ACC748547..."}]}
func ParseBridgeTx(txResponse *sdktypes.TxResponse, chainId string, msgTypes []string) ([]types.RawBridgeTx, error) {
// txResponse here is the result the same as `seid q txs --events`
for _, log := range txResponse.Logs {
for _, event := range log.Events {
...
if event.Type != transferEventType {
continue
}
...
amountCoins, err := sdktypes.ParseCoinsNormalized(amount)
for _, amountCoin := range amountCoins {
// Case: IBC Transfer Bridge In or IBC Timeout Refund
if sender == IBCTransferModuleAccount {
bridgeUserAddress = recipient
bridgeAddress = sender
bridgeTxType = IBCTransferBridgeInType
}
// Case: IBC Transfer Bridge Out
if recipient == IBCTransferModuleAccount {
bridgeUserAddress = sender
bridgeAddress = recipient
bridgeTxType = IBCTransferBridgeOutType
}
...
}
}
}
在源链上对原生代币的流入和流出金额进行索引的方法与对非原生代币进行索引的方法相同。唯一的微妙区别是，与其从IBC模块账户中计算转账信息，你应该从特定的IBC托管账户（用于你的通道）中计算。
在本报告中，我们阐述了Inter-Blockchain Communication（IBC）协议及其复杂的流入和流出索引过程的细微差异。
正如在Flipside仪表板中观察到的不一致性所证明的那样，索引中的异常可能导致社区内的误解。在使用IBC时，特别是在网络拥塞或遇到意外情况（如数据包超时）的情况下，所有利益相关方都必须意识到IBC的细微数据差异。
Sei Labs工程团队要对所有社区成员和利益相关方表达感谢，感谢他们的耐心和信任。团队已经充分配备并致力于确保我们链上所有IBC交易的透明度、准确性和效率。我们坚定不移地致力于建立信任，以维护IBC生态系统的完整性。
不想错过 Sei 的最新动态？点击下方按钮免费订阅！
“Sei中文”官方推特、Sei中文电报群、Sei中文公告电报群已开通，现在Follow来第一时间了解Sei的最新进展：
Inter-Blockchain Communication (IBC) 协议是一个开创性的框架，旨在促进独立区块链之间的安全无缝通信，使它们能够相互传输代币和数据。IBC是一项复杂而具有挑战性的技术。
在过去的几个月里，Sei实验室工程团队观察到在几个第三方服务商上，Sei区块链上OSMO代币的总流入和流出存在差异。Sei实验室团队经过调查和分析确定了问题的可能原因：这些不匹配是由第三方服务商索引和解释数据的方式导致的。值得注意的是，这并不是由于任何链级问题。
本博文将详细介绍如何发现、调查此问题，并提出两种潜在解决方案。
注：在调查后，Flipside Crypto团队被告知了此问题，并迅速修复，我们对他们的合作和支持表示感谢。
问题最初是通过Flipside报告暴露的，该报告似乎显示Sei区块链上OSMO的总流入自启动第二天以来似乎总比总流出要小。这是没有道理的 - 要进行交易流出，必须先放入代币，因此总流入必须等于或大于总流出。唯一可能发生这种情况的合理解释是Sei和Osmosis两侧IBC逻辑存在错误。
Sei实验室工程团队在Mintscan上查找了类似但不同的结果。差异如下：
为了确定这些不一致性的起源，Sei实验室工程师重新索引了Sei主网启动后的前几天数据。他们的研究证实了流入和流出总量是一致的：
(Net_Inflow_18520000_to_19300000 - Net_Outflow_18520000_to_19300000) + Bank Supply of IBC Uosmo on height 18520000 = total supply of uosmo at height 19300000.
In this equation: Net_Inflow_18520000_to_19300000 = 289607886926903
Net_Outflow_18520000_to_19300000 = 288034713858306
Bank Supply of IBC Uosmo on height 18520000 = 20685000
Bank supply of uosmo at height 19300000 = 1573193753597
Sei实验室工程师现在已经发现了两个不同的第三方数据提供商看似不一致的流入和流出总量问题，并进行了根本原因分析。
在确认链上总量确实如预期般正确匹配后，关注点转向了第三方服务商如何对IBC数据进行索引。Flipside在GitHub上开源了他们的数据模型，因此这是一个好的起点。
Flipside的数据模型通过观察区块链上的 'ibc_transfer' 活动计算IBC流出，通过观察 'write_acknowledgement' 消息和 'packet_data' 属性计算IBC流入。
让我们看一下成功的IBC转账是如何进行的：
在链A上创建数据包（源链）：
a. 链A上的用户启动向链B的代币转账。
b. 这个操作导致在链A上创建一个表示代币转账的IBC数据包。链A上的代币被保存在IBC托管账户中，确保它们不会被双重花费。需要注意的是，这里的每个通道对应一个唯一的托管账户，例如osmo<>sei通道的托管账户与axelar<>sei通道的托管账户不同。
c. 交易＃1：在链A上进行一次交易以启动转账。
将数据包中继到链B：
a. 一个中继者注意到链A上的新数据包，并提交了一笔交易到链B作为中继数据包。
b. 交易＃2：在链B上进行一次交易以接收数据包。
在链B上处理数据包（目标链）：
a. 链B处理数据包，为预期的接收方在链B上铸造相应的代币，然后生成确认。
将确认中继到链A：
a. 一个中继者注意到链B上的确认，并提交了一笔交易到链A来中继这个确认。
b. 交易＃3：在链A上进行一次交易以处理确认。
因此，如果所有的IBC转账消息都被记录，而所有的交易都按照上述方式进行，总数就会匹配，对吧？理论上是的。
实际上，有一个问题：超时。一些IBC转账创建时带有超时参数，可以指定为块高度、时间戳，有时两者都有。在此时间或块高度之后，IBC数据包将被视为超时……那么接下来会发生什么？
如果一个中继者试图将一个已超时的IBC数据包中继到链B的IBC模块，该模块将返回一个超时错误。中继者通知链A上的发送模块数据包已超时（使用TimeoutPacket）。原本要转账的代币被发送回转账发起者，IBC转账失败。
现在您已经看到了IBC转账交易的生命周期，并了解了由于超时而导致这些交易有时会失败的原因，您就能理解在数据中观察到的IBC流入/流出差异的可能原因。Sei Labs工程团队回顾了Sei区块链启动后几天的交易数据。的确有许多流出IBC转账超时的情况。
第三方数据索引器将每个ibc_transfer事件都计入IBC流出，即使该转账后来超时 - 即使转账交易在源链上最初成功，仍然有可能在中继期间超时。因此，这些数据提供商计算的总IBC流出既代表了成功的IBC转账，也代表了那些已经超时的转账。这就是为什么IBC流出大于流入的原因。
与其处理IBC转账事件以获取流入/流出金额，Sei Labs工程团队建议统计从IBC模块账户中转出或转入的所有非本地代币的总量，因为这考虑了上述所有情况（即转入、转出以及超时后的退款）。
他们提供了以下代码片段，以实现这种方法来解析金额：
// IBC Transactions: Check tx event for event type 'transfer' between ibc-transfer module account and sei account
// Example: {"type":"transfer","attributes":
// [{"key":"recipient","value":"sei1z3g0ccd0gpe6m4afjjmtxka269yyrymhwwvf3x"},
// {"key":"sender","value":"sei1yl6hdjhmkf37639730gffanpzndzdpmhrn8l3z"},
// {"key":"amount","value":"7898600ibc/2CC0B1B7A981ACC748547..."}]}
func ParseBridgeTx(txResponse *sdktypes.TxResponse, chainId string, msgTypes []string) ([]types.RawBridgeTx, error) {
// txResponse here is the result the same as `seid q txs --events`
for _, log := range txResponse.Logs {
for _, event := range log.Events {
...
if event.Type != transferEventType {
continue
}
...
amountCoins, err := sdktypes.ParseCoinsNormalized(amount)
for _, amountCoin := range amountCoins {
// Case: IBC Transfer Bridge In or IBC Timeout Refund
if sender == IBCTransferModuleAccount {
bridgeUserAddress = recipient
bridgeAddress = sender
bridgeTxType = IBCTransferBridgeInType
}
// Case: IBC Transfer Bridge Out
if recipient == IBCTransferModuleAccount {
bridgeUserAddress = sender
bridgeAddress = recipient
bridgeTxType = IBCTransferBridgeOutType
}
...
}
}
}
在源链上对原生代币的流入和流出金额进行索引的方法与对非原生代币进行索引的方法相同。唯一的微妙区别是，与其从IBC模块账户中计算转账信息，你应该从特定的IBC托管账户（用于你的通道）中计算。
在本报告中，我们阐述了Inter-Blockchain Communication（IBC）协议及其复杂的流入和流出索引过程的细微差异。
正如在Flipside仪表板中观察到的不一致性所证明的那样，索引中的异常可能导致社区内的误解。在使用IBC时，特别是在网络拥塞或遇到意外情况（如数据包超时）的情况下，所有利益相关方都必须意识到IBC的细微数据差异。
Sei Labs工程团队要对所有社区成员和利益相关方表达感谢，感谢他们的耐心和信任。团队已经充分配备并致力于确保我们链上所有IBC交易的透明度、准确性和效率。我们坚定不移地致力于建立信任，以维护IBC生态系统的完整性。
不想错过 Sei 的最新动态？点击下方按钮免费订阅！
“Sei中文”官方推特、Sei中文电报群、Sei中文公告电报群已开通，现在Follow来第一时间了解Sei的最新进展：
No activity yet