![]() This means that there is no concurrency whatsoever when a particular Merkle tree is being sequenced. Next, these jobs are distributed to a number of concurrent sequencers that work on different Merkle trees. It is determined by an election protocol which is used for coordination in the case of multiple log signers, otherwise master is assumed as there is nothing to coordinate. A sequencing job is scheduled for each Merkle tree that the log signer is currently the master for. After waking up once per interval as defined by the configured sequencer_interval, the log signer takes a pass over all Merkle trees that it manages. This requires coordination, which is one part of the forever loop. At most one log signer is responsible for a particular Merkle tree at a time though. You can also run multiple different log signers to avoid single points of failure. This allows parts of the log to be retired as soon as they are no longer needed. It might sound odd at first, but hopefully less so if you think about the existence of transparency applications that use temporal sharding: the split of one transparency log into multiple smaller ones so that the leaves are grouped by, say, yearly relevance like 20. Pretty much a busy working day! Coordinationīefore proceeding you need to know that a log signer may manage multiple different Merkle trees. In a nutshell, the log signer wakes up, performs some jobs, and goes back to sleep. For reference it is implemented by Trillian’s operation manager, see the OperationLoop function. The most central part of the log signer is probably its forever loop. For example, the sequencer job is most reliable if it runs often over small batches. The longer answer is detailed below, and it includes a little bit of additional context regarding what you may (not) do with these three parameters. In other words, to avoid building up a large backlog you need to consider how often the sequencer runs and how much work it is willing to do every time. If the interval elapsed already there will be no sleep. It sequences no more than the configured batch size before going back to sleep. The sequencer interval tells you how often the log signer wakes up to do a sequencing job.The number of sequencers is only relevant if there are multiple Merkle trees. Regardless of how many sequencers you configure there will be no concurrent sequencing of a particular Merkle tree.I don’t mean difficult as in understanding that there may be several sequencers t hat run periodically, but rather what that actually means in terms of concurrency and how much can be sequenced per time unit. Some of these options are more difficult to grasp than others, such as num_sequencers, sequencer_interval, and batch_size. Trillian’s log signer comes with a whole bunch of configuration options that are spread across several different files. I spent a few hours learning more about the details and thought shared knowledge is better. This part of the log signer is structured as a sequencing job that runs periodically. It runs in a dedicated process that basically merges pending leaves that have yet to be incorporated into the Merkle tree. That Merkle tree is managed by a separate component called a log signer. One way to view Trillian is as a database with an append-only Merkle tree. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |