Credits (CS Blockchain) code review pointing to no decentralization!

CREDITS (CS BLOCKCHAIN) CALLED BUG BOUNTY CAMPAIGN. WE OBLIGED

Bug Summary: SEVERELY CENTRALIZED NETWORK BUT SOLD A FALSE SENSE OF DECENTRALIZATION

Severity: CRITICAL

Impact: Token holders might not know this and overpaying can have financial impact in bad way

Description:

For a network that advertises a throughput of 1M TPS, there will be significant commitment of resources like disk storage, bandwidth, to run a normal node.

There are no rewards for running Normal node, however CREDITS relies on the improbable scenario people will run it as a charity to help CREDITS be decentralized. That either didn't happen, or decentralization can be easily forged.

The seed list is inside the source code, that are run by credits in a PoA manner, no one can ever split the network even if they have more resources than CREDITS, except a hard folk.

Lastly the best part — a whole new level of smoke and mirror — the decentralization cannot be verifiable based on its protocol, it relies on participants of the network to trust CREDITS.

Voting are hugely out-of-band from the the rest of the protocol and not cryptographically verifiable.

The genesis block was produced by CREDITS-run main-node, and this will be responsible for vote counting for the next set of leaders. Even if hypothetically there are non-official entities that run nodes and even if they run more nodes than CREDITS, the incumbent can rig the voting to keep CREDITS always in power.

This is akin to a Dynasty system where they choose its own successor but give an illusion of democracy by faking polls, and naive subjects of this system will believe they are a utopia.

However, do take this as a compliment of CREDITS*. We already suspected this from the protocol in whitepaper, the code confirmed it.

This bug was never reported ever since CREDITS debuted, we applaud this level of creativity that deceived the world.

The consensus is standard, with correct foundation in BFT algorithm hence won’t be covered, the focus is solely on its claim of decentralization and permissionless traits.

Simply put, it is trying to allow public node to join the network without any permission, and all nodes have equal chance if they adhere to the protocol, without trust. Using BTC as example, anyone who manage to solve the PoW will be elected to write to blockchain and be incentivized for it.

CREDITS’s protocol is put to test whether this is true and publicly verifiable and fair, and no trust is required.

According to CREDITS Decision Consensus Algorithm (CDCA).

After a block is generated and recorded in the blockchain, nodes send a request to the TNs of the next round to include them in the list of candidates for becoming a TN.

This shows that the first phase of voting is already not included in blockchain for verifiability, and not part of the larger consensus. The blockchain can only reach consensus for non-election-related transactions.

It is also unclear what incentive do TN get for accepting make-me-TN requests from strangers, a TN can pretend it is not listening and drop all but its/uts friends’ nodes. This is the first problem. Read on.

Next TNs are exchanging the lists of candidates for becoming a TN of the next round and the occurrence frequency of a candidate in the created list is analyzed. In case the candidate has a frequency of 50% (i.e. it’s included in the list of candidates in >50% of all
TNs of the current round) it automatically becomes a TN of the next round and is included in the vector “next_round_trusted”.

This shows that every TN is possible to have their own independent list of candidates. That’s why it talked about how 1 candidate can be in some TN’s CandidateList and not in another TN's CandidateList.

All other nodes that have a frequency of less than 50% are selected by a pseudo-random algorithm, by the result of which on all TNs operating under the protocol the same list of next round Trusted Nodes “next_round_trusted” is formed.

std::random_device rd;
std::mt19937 g;
g.seed((unsigned int)Conveyer::instance().currentRoundNumber());
cs::Random::shuffle(aboveThreshold.begin(), aboveThreshold.end(), g);

src: https://github.com/CREDITSCOM/node/blob/68beede19464b04912bef2104bd66d069e970eb6/solver/src/states/trustedstage3state.cpp#L509

Say if the original group of TN (most probably CREDITS) decide to collude, change the above source code, recompile and run a modified node, they can basically control next_round_trusted, in short, they can stay in power forever. Other participants can’t tell it is rigged, because they can’t complain about random element. (maybe they can if vector of CandidateList is engraved in last block considering the randomness is pseudo)

Always #DYOR and beware of moonboys

source:

• https://credits.com/Content/Docs/CDCA.pdf

References:

• https://t.me/CREDITSoffical/789
• https://developers.credits.com/en/NewsPage/Credis_Bug_Bounty

Original post:

• https://t.me/ScamsAlarm/92

Posted using Partiko Android