changelog for 5.0.7 (#923)

language/move-lang/functional-tests/tests/0L/demos/persistence.move

@@ -3,6 +3,7 @@
 
 //! account: alice, 1000000, 0, validator
 //! account: bob, 1000000, 0, validator
+//! account: carol, 1000000, 0
 
 
 ///// DEMO 1: Happy case, the State resource is initialized to Alice's account, 
@@ -20,18 +21,21 @@ script {
     // This sender argument was populated by the test harness with a random 
     // address for `alice`, which can be accessed with sender variable or 
     // the helper `{alice}`
-    fun main(sender: signer){ // alice's signer type added in tx.
-      PersistenceDemo::initialize(&sender);
-
-      PersistenceDemo::add_stuff(&sender);
-      assert(PersistenceDemo::length(&sender) == 3, 0);
-      assert(PersistenceDemo::contains(&sender, 1), 1);
+    fun main(alice: signer){ // alice's signer type added in tx.
+    //script stuff
+      PersistenceDemo::initialize(&alice);
+      PersistenceDemo::add_stuff(&alice);
+
+    // our checks
+      assert(PersistenceDemo::length(&alice) == 3, 0);
+      assert(PersistenceDemo::contains(&alice, 1), 1);
     }
 }
 
 ///// The tags with `check` matches to a string in the VM output. Here we are 
 ///// checking for a correct execution.
-// check: EXECUTED
+
+//! check: EXECUTED
 
 ///// DEMO 2: Abort if an `assert` fails.
 ///// This will fail because length is actually 3

mempool/src/shared_mempool/tasks.rs

@@ -217,7 +217,8 @@ where
     counters::PROCESS_TXN_BREAKDOWN_LATENCY
         .with_label_values(&[counters::FETCH_SEQ_NUM_LABEL])
         .observe(storage_read_latency.as_secs_f64() / transactions.len() as f64);
-
+
+    //////// 0L ////////
     let transactions: Vec<_> = transactions
         .into_iter()
         .enumerate()
@@ -227,13 +228,15 @@ where
                     return Some((t, sequence_number));
                 } else if t.sequence_number() > sequence_number{
                     statuses.push((
+
                         t,
                         (
                             MempoolStatus::new(MempoolStatusCode::VmError),
                             Some(DiscardedVMStatus::SEQUENCE_NUMBER_TOO_NEW),
                         ),
                     ));
-                }else {
+                } else {
+                      //////// end 0L ////////
                     statuses.push((
                         t,
                         (
@@ -256,6 +259,7 @@ where
         })
         .collect();
 
+
     // Track latency: VM validation
     let vm_validation_timer = counters::PROCESS_TXN_BREAKDOWN_LATENCY
         .with_label_values(&[counters::VM_VALIDATION_LABEL])

ol/changelog/5_0_7.md

@@ -0,0 +1,67 @@
+## 5.0.7
+
+
+Same as 5.0.6 this is an upgrade with patches mitigate an ongoing network incident. More details here: https://hackmd.io/KY7VklgAR72Bg7ETTQZAxA
+
+These changes do not affect Move code (no changes to system state or policies). It only upgrades `diem-node`
+
+#### TL;DR
+
+Just update binaries to use patches.
+
+```
+
+# install new binaries
+cd ~/libra
+git fetch
+git checkout v5.0.7 -f
+make bins install
+<stop diem-node>
+<restart diem-node>
+
+```
+
+### Summary
+
+TBD
+
+### Changes
+
+##### Move Changes
+None
+
+##### Rust Changes
+##### - Harden the mempool against a flood of new txs by discarding them earlier in validation 
+
+
+This change forces the shared-mempool incoming tx processing to discard any transactions with an advanced sequence number (in the future). This is to mitigate the incident described here: https://hackmd.io/KY7VklgAR72Bg7ETTQZAxA
+
+So here is the logic to this change,
+
+https://github.com/OLSF/libra/blob/main/mempool/src/shared_mempool/tasks.rs#L225-L248 rejects old sequence numbers but not new sequence numbers.
+
+but
+https://github.com/OLSF/libra/blob/main/mempool/src/shared_mempool/tasks.rs#L252-L258 but the new sequence numbers get rejected here which is a more expensive validation.
+
+Rejecting them earlier should help preserve resources
+
+One thing about this patch is that we expect -- because it only blocks txs with newer sequence numbers from other validators -- we expect that newer sequence numbers will sit in the mempool of the node that received them until the state has been updated
+
+What this regresses is the ability of a block proposer to propose sequential sequence numbers from a single account.
+
+This more useful for a payments use case than current 0L use cases. We can revert this when we pull in performance work from upstream
+
+https://github.com/OLSF/libra/pull/922
+
+
+##### Tests
+
+- All continuous integration tests passed.
+- The diem-code was tested on a "Canary rollout" to three production nodes that were both synced and out of sync.
+
+##### Compatibility
+The Move framework changes are backwards compatible with `diem-node` from v5.0.1
+
+### Rust changes
+#### Diem Node
+Changes to `diem-node` is compatible with on-chain state from `v5.0.5`.