From 9c50302a39032a8632139d9b10b6e9c9ae07fd49 Mon Sep 17 00:00:00 2001 From: Greg Fitzgerald Date: Fri, 22 Jun 2018 22:45:22 -0700 Subject: [PATCH] Update rfc-001-smart-contracts-engine.md --- rfcs/rfc-001-smart-contracts-engine.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/rfcs/rfc-001-smart-contracts-engine.md b/rfcs/rfc-001-smart-contracts-engine.md index 70f868c2e1..dc90ead245 100644 --- a/rfcs/rfc-001-smart-contracts-engine.md +++ b/rfcs/rfc-001-smart-contracts-engine.md @@ -139,12 +139,15 @@ void reduce_r( Transactions are batched and processed in parallel at each stage. +``` +-----------+ +--------------+ +---------------+ +-----------+ | sigverify |--->| debit verify |--->| memory verify |--->| execution | +-----------+ +--------------+ +---------------+ +-----------+ +``` Continued: +``` +-----------+ +---------------+ | execution |-+->| memory commit | +-----------+ | +---------------+ @@ -156,6 +159,7 @@ Continued: | +----=----------+ +->| credit commit | +---------------+ +``` The `debit verify` stage is very similar to `memory verify`. Proof of key ownership is used to check if the callers key has some state allocated with the contract, then the memory is loaded and executed. After execution stage, the dirty pages are written back by the contract. Because know all the memory accesses during execution, we can batch transactions that do not interfere with each other. We can also appy the debit and credit stages of the transaction.