Encoding Client Versions in Validator Graffiti

# Encoding Client Versions in Validator Graffiti This document assumes the user is running the following client pairs: ```python # Execution Client ClientVersionV1: code: "BU" name: "Besu" version: "24.1.1" commit: "0x9b0e38fa" ``` ```python # Consensus Client ClientVersionV1: code: "LH" name: "Lighthouse" version: "4.6.0" commit: "0x1be52536" ``` When encoding this information in block graffiti, we have the following options: ## DEFAULT CASE: user does not set graffiti or elects to customize <= 20 graffiti characters The default encoding is as follows: ``` ELcode|2bytecommit|CLcode|2bytecommit|custom_user_graffiti ``` For example: ``` BU9b0eLH1be5 ``` ``` BU9b0eLH1be5 lido staking pool! ``` **The vast majority** of the nodes we collect data from will use the default case, so it's most important to standardize this case. This standard was chosen because it is a good middle ground between several competing concerns: - space efficiency - readability - version collision resistance - compatibility with flexible standard ## SPECIAL CASE: the flexible standard We don't know yet, but it is possible that some validators would elect to provide client data if we could provide them more characters for their custom graffiti. Consensus clients are free to accommodate these users by implementing the flexible standard described below: ### User wants to specify > 20 but <= 24 graffiti characters ``` ELcode|1bytecommit|CLcode|1bytecommit|custom_user_graffiti ``` For example: ``` BU9bLH1b now this is pod racing ``` ### User wants to specify > 24 but <= 28 graffiti characters ``` ELcode|CLcode|custom_user_graffiti ``` For example: ``` BULHThis is where the fun begins ``` ### User wants to specify > 28 but <= 30 graffiti characters ``` ELcode|custom_user_graffiti ``` For example: ``` BU I don't like sand, its course ```