What is a transcript?
Last updated
Was this helpful?
Last updated
Was this helpful?
The transcript serves as an unchanging record of every step taken during task execution. It acts as the ultimate source of truth, ensuring that anyone who reviews it can accurately determine the status of a task and verify the correctness of its output. This means you can rely on the transcript to provide an accurate account of what happened during task execution.
The transcripts offer a high level of transparency, grounded in the following characteristics.
Immutability: The transcript provides an unchangeable record of everything that occurred during task execution. It's like a reliable source of truth for the entire process.
Protocol: Clear Roles and Responsibilities: The transcript clearly outlines who is responsible for what and when. This means anyone reviewing the transcript can easily determine the progress of the task and verify the accuracy of the results.
Incentives and Slashes: Rewarding Good Behavior, Correcting Mistakes: The transcript includes information about rewards and penalties for following or deviating from the protocol. This ensures that everyone involved has extra motivation to act in accordance with the established guidelines.
The main reason why we use cryptography is to verify the identity of each Truebit Verify Node that interacts with the Truebit Verify Hub within the Truebit network. Suppose that there is no cryptography strategy in between the communication of nodes and someone has solved a Truebit Task and committed the solution, someone else can copy that solution and pretend to be the owner. This is the kind of problem that we are trying to solve with cryptography.
Privacy is crucial, therefore, only the Truebit Verify Hub can unveil solutions. To achieve this, we use encryption on the Truebit Node's responses. This process involves using the public key of the Coordination Hub as input.
To prevent another worker node from copying the encrypted solution, we also include a unique "salt" (Random data fed as an additional input to a one-way function that hashes data). This "salt" is derived from the "senderAddress" (the Truebit node address) found within the encrypted solution
Lastly, we hash the whole solution using the salt and store the result in the msgHash field, and sign the message using the Truebit Node private keys. This serves to confirm the source of each message and ensures that the salt (senderAddress) matches the signer.
Furthermore, every message will bear the signature of its creator, allowing anyone interested in validating any stage of the final transcript to do so.
As was exposed in the previous section, the message solution will be encrypted with the public key of the Coordination Hub. Once the message arrives at the execution-service, this one will be able to decrypt the solution with its own private key, and after decrypting the message is now able to return the task_solved message with the clearTextSolution to the task giver via the dispatch server.
After that, it would get the senderAddress of the solution and finally verify that the message was signed with the same address as the senderAddress.
These checks are meant to be performed as we receive messages from the nodes, they should guarantee the integrity of the messages before they get added to the transcript:
Signature Check: Every message received should have a signature, this check verifies that the signer address and the sender address match.
Valid Execution ID: Check that the execution id referred in the message matches an “open” transcript and that the node is allowed to submit a response, i.e. should be a member of the node cohort selected by the dispatcher.
No Duplicate Execution Completed: A node should not be able to add more than one execution response message.
All Nodes Responded: Once that all intended nodes responded we should change the state of the transcript away from “accepting responses”. If every node responded the same way, or M out of N, where M and N are defined in the task submit, then the execution can be deemed as complete.
No replay of messages: The Hub should make sure that messages can’t be re-sent by an attacker; maybe an Execution Nonce can be used: Each node keeps track of a nonce for each task execution where it’s participating; it’s the responsibility of the Truebit Node to make sure that each Execution Nonce is appropriately incremented on each message sent to the Hub.
No partial transcripts: The Hub is trusted; external copies of the transcripts can’t be altered by an external entity so it shows incomplete data, i.e. chop last N messages.
Message order can’t be changed: The transcript is composed of messages in a sequence (assigned by the Hub). An observer can’t change the order of this messages without invalidating signatures and hashes in the Transcript.
Message Hashes should be checked: Each signed and hashed message should be checked by re-hashing the content of the message and comparing it to the provided hash; furthermore the signature should check using the computed hash.
Truebit Nodes version checked: Each node should have the expected protocol version in order to be part of the compute. The coordination Hub is aware of the version to be used and Truebit Nodes are notified.
