ripple(瑞波)区块链信任列表配置方式及expiration有效性判断说明

程序员文章站 2022-07-14 16:06:21

...

ripple(瑞波)区块链信任列表配置方式及有效性判断说明

ripple信任列表配置方式

配置文件的[validators]

直接在配置文件的[validators]配置项下面，一个节点公钥一行的形式，进行配置，这种配置为本地配置。配置示例：

[validators]
****hChCVVVHfRtVRm3xJMDVEpW1uyaFi8fjYTDCoYNY4WgeeijE
****JQtn6iP7bNVtM3JCPx28z49YuZjgPL268BrzfCdBsnhy6yiy
****49TwPEzM48sKPfQDJKiiUu2KiWFJujwpGkzGivDRABXtWRbi

配置文件的[validator_list_sites]和[validator_list_keys]

这种需要有一个信任的服务器，该服务器对外公开发布信任度高的节点公钥列表，同时提供一个列表有效时间点。这种配置为远程配置。
其中[validator_list_sites]配置服务器获取信任列表的URL，[validator_list_keys]配置服务器的公钥用于验签。配置示例：

[validator_list_sites]
http://127.0.0.1:8000
[validator_list_keys]
029d1f40fc569fff2a76417008d98936a04417db0758c8ab123dee6dbd08d79398

远程服务器信任列表示例：

{
    "sequence": 1,
    "expiration":"2020-02-07 16:50:00",
    "validators": [
        {
            "validation_public_key": "****891C7BA2C276B4180AA4E8E5DECF88F06686B3A9AFB6709064393D51654325"
        },
        {
            "validation_public_key": "****8663F808393964CD4CE236056ECEF4CED217F9CE28F43537B0FDE14F62619E"
        },
        {
            "validation_public_key": "****E886143819F704238FBE0CE2431BC36D392E81036D39BBD21063FDCD558D3E"
        }
    ]
}

配置文件的[validators_file]

这种配置方式其实是上面两种的归纳，这里需要指定一个文件的路径，而这个文件的内容就是上面两种配置或者任意一种。
配置示例：

[validators_file]
/home/ripple/validators.txt

validator.txt示例：

[validators]
****hChCVVVHfRtVRm3xJMDVEpW1uyaFi8fjYTDCoYNY4WgeeijE
****JQtn6iP7bNVtM3JCPx28z49YuZjgPL268BrzfCdBsnhy6yiy
****49TwPEzM48sKPfQDJKiiUu2KiWFJujwpGkzGivDRABXtWRbi
[validator_list_sites]
http://127.0.0.1:8000
[validator_list_keys]
****1f40fc569fff2a76417008d98936a04417db0758c8ab123dee6dbd08d79398

ripple信任列表相关属性

为了保证信任列表的有效性，chainsql设置一些信任列表的属性和判断方式。首先在代码中维护了两个重要的map。分别是

hash_map<PublicKey, PublisherList> publisherLists_;
hash_map<PublicKey, std::size_t> keyListings_;

publisherLists_

这个map是以信任列表发布者的公钥为key，PublisherList为value组成的。其中PublisherList为结构体，有四个属性，分别是：

struct PublisherList
{
    bool available;
    std::vector<PublicKey> list;
    std::size_t sequence;
    TimeKeeper::time_point expiration;
};

也就是说，如果同时有本地配置和远程配置的话（且远程配置只配置了一个server），那么publisherLists_就有两个元素。
其中本地配置的key是一个空值，然后本地配置的PublisherList的expiration为无限大。available为true；
而远程配置的key为远程服务器的公钥，即配置项中的[validator_list_keys]，而远程配置的PublisherList的各个属性由远程配置决定。其中available是由节点判断之后确定的。

keyListings_

这个map其实是所有信任列表的集合，即key是信任节点公钥，value是该信任节点出现的次数。比如一个信任节点在本地配置了，同时又从远程配置中解析到，那么它的value即为2。
本节点自己的公钥也会出现在这个map中。

信任节点列表是否有效判断说明

远程配置每次更新判断
当配置了远程服务器配置，每次获取到的list都会进行超时判断，即远程服务器配置信任列表的超时时间是否过期，一旦过期，则不会将这次更新获取的信任列表保存。
每轮共识开始判断
在onConsensusStart函数中，即每轮共识开始，都会结合上一次有过通信的验证节点列表（即keySet seenValidators）以及当前的publisherLists_和keyListings_去决定本轮的quorum。因此quorum不是一成不变的。

函数开始会将allListsAvailable赋值true，然后对publisherLists_进行PublisherList的expiration判断，只要有一个list超时，则将allListsAvailable设置为false；
由keyListings_和seenValidators整合除一个临时有效共识列表rankedKeys；
然后由keyListings_计算一个最小quorum值。
根据rankedKeys的元素个数与BYZANTINE_THRESHOLD（32）进行比较，如果大于，则调整quorum或者应当有多少共识节点总个数。
根据下面代码最终确定quorum值：

if (minimumQuorum_ && seenValidators.size() < quorum)
{
    quorum = *minimumQuorum_;
    JLOG (j_.warn())
        << "Using unsafe quorum of "
        << quorum_
        << " as specified in the command line";
}
// Do not use achievable quorum until lists from all configured
// publishers are available
else if (! allListsAvailable)
    quorum = std::numeric_limits<std::size_t>::max();

minimumQuorum_来自配置文件的[quorum]配置项，认为是人为配置的最小quorum数。（如果没有配置，该值在此为false）；
即当minimumQuorum_有值以及当可见验证节点数量小于计算出的quorum，此时quorum取minimumQuorum_。
还有一种情况就是allListsAvailable，即任意一个信任列表超时，就会将quorum设置为无限大。此时就会出现无法继续共识的情况。，不过只要对应信任列表的服务器及时更新了超时时间，下次能够更新的话，还是可以继续共识。