问题标签 [tendermint]

我正在尝试使用指南链接安装tendermint：[ https://tendermint.com/docs/introduction/quick-start.html#cluster-of-nodes]

我在 virtualbox 上安装的 4 个不同的虚拟机中执行此操作

所有机器都可以ping通并且有不同的IP地址

尽管如此，我还是得到了错误：没有要拨号的地址，也没有连接的对等方。当我运行命令时回退到种子模块 = p2p

嫩薄荷节点 --home ./mytestnet/node0 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656" 嫩薄荷节点 -- home ./mytestnet/node1 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656" 嫩薄荷节点 --home ./mytestnet /node2 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656" 嫩薄荷节点 --home ./mytestnet/node3 -- proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656"

我在尝试设置 bigchaindb 服务器时遇到了类似的问题。是否需要在 VM 上进行任何其他设置，或者我们需要真正的 ubuntu 机器而不是 VM

我正在尝试使用命令安装 abci-app ( kvstore )，make install_abci 但出现以下错误：

我无法确定我收到此错误的原因。是否有任何替代方法来安装 abci-app。

Tendermint 似乎缺少对块创建时间的描述......
他们将默认配置文件创建为

我阅读文档和代码。

所以在我的猜测中，如果tendermint 在一轮内成功创建区块，
timeout_propose + timeout_prevote + timeout_precommit = 5s 并等待 timeout_commit 5s ......
所以区块提交发生在 5s~10s 因此下一个区块共识在 10s 之后开始。

如果tendermint在两轮中成功创建块，
(timeout_propose + timeout_prevote + timeout_precommit) + (timeout_propose + timeout_propose_delta + timeout_prevote + timeout_prevot_delta + timeout_precommit + timeout_precommit_delta) = 5s + 6.5s = 11.5s 并等待 timeout_commit 5s...
所以块提交发生在 11.5s~16.5s 之间，因此下一个区块共识在 16.5s 之后开始。我猜tendermint 会为每一轮添加增量超时。

我的猜测对吗？如果不是，配置文件中的超时究竟是什么意思？

我在这里关注 Cosmos SDK 教程，运行时出现以下错误make localnet-start

我尝试使用sudo但得到了同样的错误。知道为什么吗？提前致谢。

在运行此代码（我在 lotion js 官方网站上找到）时，我收到此错误

可以这样做吗？

我想在单个事务中存储多个数据，那么可以使用键值对或任何其他可行的技术来完成吗？

所以，我有这种情况，即 2/3 的验证者不诚实，他们可以进行欺诈交易。可以做些什么来防止它，我怎么知道哪 2/3 是欺诈？那时 PBFT 行不通，对吧？

如果 2/3 不诚实怎么办？

有什么解决办法吗？

目前，tendermint 的默认数据库是 LevelDB，但我想使用 mongoDB，但没有找到任何有用的文档。那么，任何人都可以提供帮助，甚至有可能吗？这是可能的，我看到了，但是怎么做呢？

我正在尝试运行 8 个容器。4 个节点和 4 个 abci 节点。这是我的 docker-compose 文件

这个想法是将每个节点连接到它的 abci 节点。要在所有节点之间共享的配置文件位于目录下名为 build 的文件夹中。

它应该开始互相发送请求。但相反，它给了。

正如您在上面看到的 abci 容器工作正常。但连接被拒绝。

我目前正在一个使用 Tendermint 的小型交易平台工作，但我还不确定应该如何使用 Tendermint 应用程序状态。在https://tendermint.com/docs/app-dev/abci-spec.html#message-types下的 Tendermint 文档中，它说：

请注意，消息可能会在所有连接上同时发送——一个典型的应用程序将因此为每个连接维护一个不同的状态。它们可以分别称为 DeliverTx 状态、CheckTx 状态和 Commit 状态。

我会告诉你我应该如何使用这三种状态的理解，希望你能告诉我这是否正确。

• DeliverTx 状态：在 ABCI 应用程序收到每个有效的 DeliverTx 请求消息后，此状态会更新。如果交易无效（由拜占庭提议者包含），DeliverTx 状态将重置为先前在收到最后一个 CommitTx 消息时设置的CommitTx 状态。
• CommitTx 状态：当 ABCI 应用程序接收到 CommitTx 消息时，将CommitTx 状态设置为最新的DeliverTx 状态。
• CheckTx 状态：可能用于 DoS 保护（通过将过去几秒钟内通过 CheckTx 请求消息到达的事务数存储为CheckTx 状态，并且每当每秒的事务数变得过高时，CheckTx 响应就会拒绝事务进入内存池）。
• 此外，无论何时（通过 abci_query RPC 端点）查询应用程序，应用程序都会根据其CommitTx 状态回答查询

我对这三种状态的看法可能已经暗示我不确定当应用程序接收到 DeliverTx 请求但交付的交易无效时会发生什么（这种情况甚至会发生吗？）。提议、预投票和预提交的整个过程实际上与这些消息类型（CheckTx、DeliverTx、Commit）有什么关系？