casper-network / casper-node

Reference client for CASPER protocol

Home Page:https://casper.network

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

BlockValidator can sometimes drop responders without responding

SaiProServ opened this issue · comments

If the BlockValidator receives two requests for validating the same block in quick succession (a valid scenario if we learn of new holders of the same proposal), it is possible that the second one will arrive before the state for the first one is inserted into validation_states, in which case both will be processed as new requests and the responder and holder for the first one will end up being dropped.

Hi Vibrant Casper's Dev community ! 💯
i hope i'm not disrispect or trolling by commenting this particular issue but it rememeber this particular point being discussed (and published at IOHK). Here is basically how they handle it there :

_In the Cardano blockchain, the BlockValidator is designed to handle such scenarios to prevent the issue you described. Here's a simplified explanation of how it might be handled:

  1. Concurrency Control: The BlockValidator is likely designed to handle concurrent requests. This means that even if two requests for validating the same block arrive in quick succession, they won't interfere with each other's processing.

  2. State Management: The validation_states you mentioned is likely a data structure used to keep track of the validation process for each block. When a new request comes in, the BlockValidator would first check this data structure to see if the block is already being processed. If it is, the new request would be queued or discarded, depending on the specific implementation.

  3. Unique Identifiers: Each block validation request might have a unique identifier associated with it. This could be the block hash or some other unique value. This identifier would be used to check if a request is already being processed, as mentioned in the previous point.

  4. Responder and Holder Management: The responder and holder for each request would be managed in such a way that they aren't dropped until the validation process is complete. This could be done by keeping references to them in the validation_states data structure, for example.

In the specific case of Cardano, the Ouroboros protocol, which is the consensus mechanism used by Cardano, is designed to handle such scenarios. However, the exact details of how this is done would depend on the specific implementation of the BlockValidator and the rest of the Cardano node software. For the most accurate information, it would be best to refer to the official Cardano documentation or the source code of the Cardano node software._

May it help/inspires @SaiProServ . If not i send all my luck and best wishes to hard working dev and Casper's community.

Best,

Simon