В тех же лайтах подобное происходит десятки раз в день.
И тем не менее, лайты при совпадении эквивалента "траста", т.е. nChainWork, делают дополнитеьное сравнение хешей блоков, что бы более однозначно сказать, какой из блоков выигрывает:
Code:
struct CBlockIndexWorkComparator
{
bool operator()(CBlockIndex *pa, CBlockIndex *pb) {
if (pa->nChainWork > pb->nChainWork) return false;
if (pa->nChainWork < pb->nChainWork) return true;
if (pa->GetBlockHash() < pb->GetBlockHash()) return false;
if (pa->GetBlockHash() > pb->GetBlockHash()) return true;
return false; // identical blocks
}
};
{
bool operator()(CBlockIndex *pa, CBlockIndex *pb) {
if (pa->nChainWork > pb->nChainWork) return false;
if (pa->nChainWork < pb->nChainWork) return true;
if (pa->GetBlockHash() < pb->GetBlockHash()) return false;
if (pa->GetBlockHash() > pb->GetBlockHash()) return true;
return false; // identical blocks
}
};
Вообще же, хэш proof-of-stake блока не имеет какой-либо ценности, да и не должен. Добавление подобной проверки позволит юзеру создавать блоки-близнецы с разным приоритетом, а это уже будет на самом деле уязвимостью.
Думаю, что лайтам следовало бы тут сравнивать не хеш блока, а сам PoW, а то что у них получилось - результат просто кат-н-пэйст. Чем уязвим вариант со сравнением hashProofOfStake в нашем случае? Чем он более уязвим, чем генерация двух блоков на одном ядре, опубликование одной версии и удержание другой с последующим майном потомка для удержанного и публикацией этой "сторонней" цепочки по нахождению такового?
