The current method for extranonce_prefix generation simply increments a uint, which has size/resiliency trade-offs. Theoritically the extranonce_prefix for a single server only needs 2 bytes since the servers will not run more than 65k connections. Incrementing a u16 for extranonce prefix is not wise because connections drop and reconnect all the time meaning extranonce_prefixes will wrap on saturation and get reused which duplicates work. To fix this, the current method allocates a larger extranonce prefix so that it will never wrap, but this comes at the cost of coinbase space.
A more efficient method is to use a constant size bitvec with length equal to the number of connections the stratum server would like to allow. When a client connects, the extranonce prefix will be the index of an open slot in the bitvec. When a client disconnects, the slot can be freed so future connection can reuse the extranonce prefix.
The current method for extranonce_prefix generation simply increments a uint, which has size/resiliency trade-offs. Theoritically the extranonce_prefix for a single server only needs 2 bytes since the servers will not run more than 65k connections. Incrementing a u16 for extranonce prefix is not wise because connections drop and reconnect all the time meaning extranonce_prefixes will wrap on saturation and get reused which duplicates work. To fix this, the current method allocates a larger extranonce prefix so that it will never wrap, but this comes at the cost of coinbase space.
A more efficient method is to use a constant size bitvec with length equal to the number of connections the stratum server would like to allow. When a client connects, the extranonce prefix will be the index of an open slot in the bitvec. When a client disconnects, the slot can be freed so future connection can reuse the extranonce prefix.