From 93372ea556d56cdbed3e2fedd46ae3dee44301a1 Mon Sep 17 00:00:00 2001
From: Wen <113942165+wen-coding@users.noreply.github.com>
Date: Wed, 11 Dec 2024 14:13:53 -0800
Subject: [PATCH] Address review comments.

---
 proposals/0165-async-vote-execution.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/proposals/0165-async-vote-execution.md b/proposals/0165-async-vote-execution.md
index 1674ccf96..83fa1db41 100644
--- a/proposals/0165-async-vote-execution.md
+++ b/proposals/0165-async-vote-execution.md
@@ -28,12 +28,12 @@ will have fewer forks that are caused by slow transaction execution.
 ## Motivation
 
 Currently the vote transactions and non-vote transactions are mixed together in
-a block, the vote transactions are only processed in consensus when the whole
-block has been frozen and all transactions in the block have been verified and
-executed. This is a problem because slow running non-vote transactions may
-affect how fast the votes are processed and then affect the ability of
-consensus to pick the correct fork. It may also mean that the leader will more
-often build on a minority fork so the blocks it packed will be discarded later.
+a block, a block is considered in consensus only after the whole block has been
+frozen and all transactions in the block have been verified and executed. This
+is a problem because slow running non-vote transactions may affect affect the
+ability of consensus to pick the correct fork. It may also mean that the leader
+will more often build on a minority fork so the blocks it packed will be
+discarded later.
 
 With different hardware and running environment, there will always be some
 difference on speed of transaction execution between validators. Generally
@@ -100,8 +100,8 @@ Two new fields will be added to `TowerSync` vote transaction:
 The `hash` and `slot` in the `TowerSync` transaction will be updated to
 the vote only hash. The vote only hash is calculated as follows:
 
-1. Sort all vote accounts with non-zero stake in the current epoch by
-vote account pubkey.
+1. Sort all vote accounts with non-zero stake in the current or previous
+epoch by vote account pubkey.
 
 2. Calculate vote account hash by hashing (vote account pubkey,
 serialized vote state) in the order given.