From 8dba53e494d0852fc94ae978c5fe9d89e7c2f42f Mon Sep 17 00:00:00 2001 From: anatoly yakovenko Date: Sat, 23 Jun 2018 06:14:52 -0700 Subject: [PATCH] debit undo (#423) --- rfcs/rfc-001-smart-contracts-engine.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/rfcs/rfc-001-smart-contracts-engine.md b/rfcs/rfc-001-smart-contracts-engine.md index 5fad5b84ac..60db5fcf95 100644 --- a/rfcs/rfc-001-smart-contracts-engine.md +++ b/rfcs/rfc-001-smart-contracts-engine.md @@ -132,7 +132,7 @@ void reduce_r( const uint8_t *reduce_data[], int num, uint8_t *reduce_data, -); +); ``` ### Execution @@ -140,19 +140,20 @@ void reduce_r( Transactions are batched and processed in parallel at each stage. ``` +-----------+ +--------------+ +-----------+ +---------------+ -| sigverify |-+->| debit verify |---+->| execution |-+->| memory commit | +| sigverify |-+->| debit commit |---+->| execution |-+->| memory commit | +-----------+ | +--------------+ | +-----------+ | +---------------+ - | | | - | +---------------+ | | +--------------+ - |->| memory verify |->+ +->| debit commit | - +---------------+ | +--------------+ - | - | +----=----------+ + | | | + | +---------------+ | | +--------------+ + |->| memory verify |->+ +->| debit undo | + +---------------+ | +--------------+ + | + | +---------------+ +->| 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 apply the debit and credit stages of the transaction. +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 apply the `debit undo` and `credit commit` stages of the transaction. `debit undo` is run in case of an exception during contract execution, only transfers may be reversed, fees are commited to solana. ### GPU execution