Improve clarity and grammatical accuracy in technical descriptions

cairo/kakarot-ssj/docs/general/contract_bytecode.md

@@ -1,8 +1,7 @@
 # Bytecode Storage Methods for Kakarot on Starknet
 
 The bytecode is the compiled version of a contract, and it is what the Kakarot
-EVM will execute when a contract is called. As Kakarot's state is embedded into
-the Starknet chain it is deployed on, contracts are not actually "deployed" on
+EVM will execute when a contract is called. As Kakarot's state is embedded in the Starknet chain where it is deployed, contracts are not actually "deployed" on
 Kakarot: instead, the EVM bytecode of the deployed contract is first executed,
 and the returned data is then stored on-chain at a particular storage address
 inside the Starknet contract corresponding to the contract's EVM address, whose

cairo/kakarot-ssj/docs/general/machine.md

@@ -15,14 +15,14 @@ contexts, which were used to model the execution of sub-calls. However, this
 design was not possible to implement in Cairo, as Cairo does not support the use
 of `Nullable` types containing dictionaries. Since the `ExecutionContext` struct
 contains such `Nullable` types, we had to change the design of the EVM to use a
-machine with a single stack and memory, which are our dict-based data
+machine with a single stack and memory, which as our dict-based data
 structures.
 
 ## The Kakarot Machine design
 
 To overcome the problem stated above, we have come up with the following design:
 
-- There is only one instance of the Memory and the Stack, which is shared
+- There only one instance of Memory and Stack, which are shared
   between the different execution contexts.
 - Each execution context has its own identifier `id`, which uniquely identifies
   it.