Jump to content
Sign in to follow this  
karstnDE

Unable to reproduce peer/validator identifier hash

Recommended Posts

Hi all,

I'm trying to understand the heart of the XRPL, the consensus algorithm. I started with digging through some verbose ("trace"-level) logs to better understand what happens during the 3-4 seconds ledger close time. Simply put in beginning we receive peer proposals for transaction sets, build our own set and the voting/ proposal adaption rounds begin, etc.

During that process a 40-character hash is used to identify a peer (validator) that is for example proposing transaction sets. Example:

2019-Jun-24 09:24:28.602014450 LedgerConsensus:DBG Peer EAA736D07879B900E2CF0297F882FF8D13045C21 votes NO on 3EFFE2928F57AC0A5CC65E3C0E9A44A738D78D2DA41C6CA033B85DE516ACD6E5

 

The same identifier can be found in the response of the consensus_info command. The identifier is used as key in the peer_positions object (see below/attached).

image.png.bcde5ccdb505a25253314e13d40d657f.png

As you can see from the consensus_info outcome, the identifier belongs to "n9KGP..." which then seems to belong to rabbitkick.club.

 

I'm trying to understand for quite some time how this 40-character/160-bit hash is built. I kept digging through the rippled code but my understanding is not deep enough. It seems to be called "nodeID" in the code and might be a RIPEMD160(SHA256) hash, but I couldn't reproduce the outcome. 

Anyone? 

 

Thanks

Share this post


Link to post
Share on other sites

It's calculated here:

https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/protocol/impl/PublicKey.cpp#L306:L319

With this:

https://github.com/ripple/rippled/blob/5214b3c1b09749420ed0682a2e49fbbd759741e5/src/ripple/protocol/digest.h#L121:L180

(Which uses what I would assume to be equivalent implementations.)

So, indeed looks like you SHA256 the public key, then RIPDEMD160 it.  Maybe test your hashing code with known inputs and results for both the SHA256 and the RIPEMD160?  Then you can narrow down if its your code, or what you're supplying to it.

Share this post


Link to post
Share on other sites

@Professor Hantzen is correct. It’s not clear why you’re getting a mismatch, but it’s fair to say there’s an issue with your implementation.

The easiest way to track that issue down might be for you to share a snippet of the code you use, and an example of how you call it.

 

Share this post


Link to post
Share on other sites

Thanks for your help! I found the error after your assurance that I'm on the right track. ;-)

I'll think about putting a string converter between all the different encodings and key types online as I didn't find a good one online for the XRPL case - esp. as you need to use the Ripple alphabet for the base58 encodings. Something like that would have helped me a lot to understand the details.

Share this post


Link to post
Share on other sites

Already having a few verified examples ("the key 0x1234... (little endian, hex encoding) is in base58 format: rabcd..., in base64 format: c3pO..., its hashes are: sha256: 0x9999... ripemd160: 0x1111..., sha512half (NOT sha512/256!): 0x5555...") could be very helpful I guess.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...