it compiles i guess

Author: emwang-jump

src/discof/forest/fd_forest.c

@@ -1074,13 +1074,13 @@ fd_forest_publish( fd_forest_t * forest, ulong new_root_slot ) {
 #define SLOT_INSERT 1
 
 int
-fd_forest_evict( fd_forest_t * forest, ulong new_slot, ulong parent_slot ) {
+fd_forest_evict( fd_forest_t * forest, ulong new_slot, ulong parent_slot  ) {
   FD_LOG_NOTICE(( "fd_forest_eviction_time" ));
   fd_forest_ancestry_t * ancestry = fd_forest_ancestry( forest );
   fd_forest_frontier_t * frontier = fd_forest_frontier( forest );
   fd_forest_subtlist_t * subtlist = fd_forest_subtlist( forest );
+  fd_forest_orphaned_t * orphaned = fd_forest_orphaned( forest );
   fd_forest_blk_t *      pool     = fd_forest_pool( forest );
-  ulong                  null     = fd_forest_pool_idx_null( pool );
 
 
   int has_orphans   = !fd_forest_subtlist_is_empty( subtlist, pool );
@@ -1089,42 +1089,50 @@ fd_forest_evict( fd_forest_t * forest, ulong new_slot, ulong parent_slot ) {
   /* During regular operation there's usually no orphans, but if eviction
      is called then it's likely we have orphans. */
   if( FD_LIKELY( has_orphans ) ) {
+
     /* We'll keep it if it's older than all of our orphans, or if it's
        parent is part of the main tree. */
-
-    ulong evict_orphan_slot = ULONG_MAX; /* best orphan candidate for eviction is the newest subtree. */
+    fd_forest_blk_t * evict_orphan = NULL; /* best orphan candidate for eviction is the newest subtree. */
     for( fd_forest_subtlist_iter_t iter = fd_forest_subtlist_iter_fwd_init( subtlist, pool );
                                          !fd_forest_subtlist_iter_done( iter, subtlist, pool );
                                    iter = fd_forest_subtlist_iter_fwd_next( iter, subtlist, pool ) ) {
       fd_forest_blk_t * ele = fd_forest_subtlist_iter_ele( iter, subtlist, pool );
-      if( FD_LIKELY( evict_orphan_slot == ULONG_MAX ) ) evict_orphan_slot = ele->slot;
-      else                                              evict_orphan_slot = fd_ulong_max( evict_orphan_slot, ele->slot );
+      if( FD_LIKELY( evict_orphan == NULL ) ) evict_orphan = ele;
+      else                                    evict_orphan = fd_ptr_if( evict_orphan->slot < ele->slot, ele, evict_orphan );
+    }
 
+    for( fd_forest_orphaned_iter_t iter = fd_forest_orphaned_iter_init( orphaned, pool );
+                                          !fd_forest_orphaned_iter_done( iter, orphaned, pool );
+                                    iter = fd_forest_orphaned_iter_next( iter, orphaned, pool ) ) {
+      fd_forest_blk_t * ele = fd_forest_orphaned_iter_ele( iter, orphaned, pool );
+      evict_orphan          = fd_ptr_if( evict_orphan->slot < ele->slot, ele, evict_orphan );
     }
-    /* We are connecting to the main tree. Nuke the orphan. */
+    /* Now we have the max of all subtrees and orphans. This is our best candidate for eviction. */
+
+    /* If are connecting to the main tree. Nuke the best candidate orphan. */
     if( fd_forest_ancestry_ele_query( ancestry, &parent_slot, NULL, pool ) ||
         fd_forest_frontier_ele_query( frontier, &parent_slot, NULL, pool ) ) {
-      // evict_orphan_slot
-
+      subtrees_orphaned_remove( forest, evict_orphan->slot );
+      requests_remove( forest, fd_forest_orphreqs( forest ), fd_forest_orphlist( forest ), &forest->orphiter, fd_forest_pool_idx( pool, evict_orphan ) );
+      fd_forest_pool_ele_release( pool, evict_orphan );
       return SLOT_INSERT;
     }
 
-
-    /* We ourselves are an orphan. Should we evict something else or just evict ourselves?
+    /* The new slot an orphan. Should we evict the candidate orphan or insert ourselves?
        We'll keep it if it's older than all of our orphans */
-    for( fd_forest_subtlist_iter_t iter = fd_forest_subtlist_iter_fwd_init( subtlist,       pool );
-                                         !fd_forest_subtlist_iter_done    ( iter, subtlist, pool );
-                                   iter = fd_forest_subtlist_iter_fwd_next( iter, subtlist, pool ) ) {
-      fd_forest_blk_t * ele = fd_forest_subtlist_iter_ele( iter, subtlist, pool );
-      if( FD_LIKELY( new_slot > ele->slot ) ) {
-        return SLOT_IGNORE;
-      }
+
+    if( evict_orphan->slot < new_slot ) {
+      return SLOT_IGNORE;
+    } else {
+      subtrees_orphaned_remove( forest, evict_orphan->slot );
+      requests_remove( forest, fd_forest_orphreqs( forest ), fd_forest_orphlist( forest ), &forest->orphiter, fd_forest_pool_idx( pool, evict_orphan ) );
+      fd_forest_pool_ele_release( pool, evict_orphan );
+      return SLOT_INSERT;
     }
 
-    // choose something to evict from orphans
-    return SLOT_INSERT;
   } else {
-    /* Have no orphans. */
+    /* Have no orphans.  Considering the most extreme case where someone
+       has DoSed us with 10000 slots that chain to the root. */
 
     if( FD_LIKELY( parent_exists ) ) {
       /* Parent exists. This slot chains to the main tree.  From oldest to newest,
@@ -1158,18 +1166,16 @@ fd_forest_evict( fd_forest_t * forest, ulong new_slot, ulong parent_slot ) {
         else                             return SLOT_IGNORE;
       } else {
         /* evict slot found. EVICT IT. */
-
+        fd_forest_blk_t * evict_ele = fd_forest_frontier_ele_remove( frontier, &evict_slot, NULL, pool );
+        requests_remove( forest, fd_forest_requests( forest ), fd_forest_reqslist( forest ), &forest->iter, fd_forest_pool_idx( pool, evict_ele ) );
+        fd_forest_pool_ele_release( pool, evict_ele );
         return SLOT_INSERT;
       }
     } else {
       /* Parent does not exist.  This new slot would've been added as an orphan. */
       return SLOT_IGNORE;
     }
   }
-
-
-
-
 }
 
 ulong

src/discof/forest/fd_forest.h

@@ -811,11 +811,12 @@ fd_forest_merkle_last_incorrect_idx( fd_forest_blk_t * ele ) {
 fd_forest_blk_t const *
 fd_forest_publish( fd_forest_t * forest, ulong slot );
 
-/* fd_forest_eviction is called when the forest has no more free elements,
-   but we are trying to insert a new block.  When this happens, forest
-   begins evicting in the following order:
+/* fd_forest_evict is called when the forest has no more free elements,
+   but we are trying to insert a new block.  ts is fucked up tbh.
+   When this happens, forest begins evicting in the following order:
 
      1. Orphaned   slots
+     2. TODO: maybe we will want to process confirmations on orphans as well - in that case we evict unconfirmed orphans first.
      2. Connected, unconfirmed blocks
      3. Connected, confirmed blocks
 
@@ -841,8 +842,58 @@ fd_forest_publish( fd_forest_t * forest, ulong slot );
   and again, and we never make progress towards completing catchup.
 
   So we need to evict orphans ONLY if the slot being added is closer to
-  the root. Thus the eviction unfortunately depends on what's being
+  the root. Thus the eviction is stateful and depends on what's being
   added.
+
+  NO ORPHANS. EVEN MORE UNFORTUNATE CASE. SAD.
+
+  Now if we don't have orphans, we need to evict the newest unconfirmed leaf.
+  I.e. start by trimming from the tip of the tree, but ideally on a
+  fork that is a minority.
+
+  i.e best case:
+
+  1 ── 2 ── 4 ── 6 ── 7 ── 8 ...... ── 1000           <- 1001 would like to be added to the rree
+       └── 3 ── 5
+
+  If 1000 is confirmed, and 5 is not, we should evict 5 first, and then add 1001.
+
+  1 ── 2 ── 4 ── 6 ── 7 ── 8 ...... ── 1000 ── 1001   <- 1002 would like to be added to the rree
+       └── 3
+
+  Similarly, after 1002 arrives:
+  1 ── 2 ── 4 ── 6 ── 7 ── 8 ...... ── 1000 ── 1001 ── 1002   <- 1003 would like to be added to the rree
+
+  Now we have one fork, with 1003 chaining to 1002.  If 1002 is
+  confirmed, then it's truly unfortunate... We (and most likely the
+  cluster) hasn't rooted in max_live_slots!  As long as 2 is also
+  confirmed, then we are just going to optimistically publish forward to
+  slot 2 and make it our new root. Note 2 MUST have undergone
+  fec_chain_verify before it can be confirmed.  If 2 is still not
+  confirmed, we could still be in the process of evicting + repairing
+  duplicates, so we must wait for 2 to be confirmed before we can
+  publish forward.
+
+  If 1002 is NOT confirmed, we cannot evict it and add 1003. This just
+  puts us in an infinite loop of evicting slots + adding newer slots.  TODO: don't know what to do in this case.
+
+  If 1003 is chaining to 1001, i.e., it's creating a new fork.
+
+  TODO idk actually
+
+  This also works in the degenerate DoS case, where we have an extremely
+  wide tree. Imagine someone someone with leader slots 1001 thru 1995 is
+  doing the following attck:
+
+  1 ── 2 ── 3 ── 4 ── 5 ──       <-- when we try to add 6, we run into eviction policy
+                 ├── 1001'
+                 ├── 1003'
+                 ...
+                 └── 1995'
+  Even if the confirmation for 5 is lagging coming in (or it requires us
+  to replay 6 to see it), we can follow a general policy of evicting the
+  newest unconfirmed leaf. Newest implies furthest from the root. So we
+  would evict 1995' first, and then add 6.
 */
 
 int