Update doc/src/learn/architecture/validators.md

Co-authored-by: François Garillot <[email protected]>

doc/src/learn/architecture/validators.md

@@ -46,7 +46,7 @@ Narwhal enables the parallel ordering of transactions into batches that are coll
 
 Consensus sequences certificates of transactions. These represent transactions that have already been presented to 2/3 of validators that checked that all their owned objects are available to be operated on and signed the transaction. Upon a certificate being sequenced, what we do is set the *lock* of the shared objects at the next available version to map to the execution of that certificate. So for example if we have a shared object X at version 2, and we sequence certificate T, we store T -> [(X, 2)]. That is all we do when we reach consensus, and as a result we are able to ingest a lot of sequenced transactions.
 
-Now, once this is done Sui can execute all certificates that had their locks set, on one or multiple cores (currently). Obviously, transactions for earlier versions of objects need to be processed first (causally), and that reduces the degree of concurrency. The read and write set of the transaction can be statically determined from its (object, version) inputs--execution can only read/write an object that was an input to the transaction, or that was created by the transaction.
+Now, once this is done Sui can execute all certificates that had their locks set, on one or multiple cores (currently). Obviously, transactions for earlier versions of objects need to be processed first (causally), and that reduces the degree of concurrency. The read and write set of the transaction can be statically determined from its versioned object inputs--execution can only read/write an object that was an input to the transaction, or that was created by the transaction.
 
 ## Further reading