# DLOFTBs – Fast Tracking of Deformable Linear Objects with B-splines

Piotr Kicki1, Amadeusz Szymko1 and Krzysztof Walas1 This work is supported by
the European Union’s Horizon 2020 Research and Innovation Programme under
grant agreement No 870133, REMODEL.1 Institute of Robotics and Machine
Intelligence, Poznan University of Technology, Poznan, Poland; e-mail:
<EMAIL_ADDRESS>
###### Abstract

While manipulating rigid objects is an extensively explored research topic,
deformable linear object (DLO) manipulation seems significantly
underdeveloped. A potential reason for this is the inherent difficulty in
describing and observing the state of the DLO as its geometry changes during
manipulation. This paper proposes an algorithm for fast-tracking the shape of
a DLO based on the masked image. Having no prior knowledge about the tracked
object, the proposed method finds a reliable representation of the shape of
the tracked object within tens of milliseconds. This algorithm’s main idea is
to first skeletonize the DLO mask image, walk through the parts of the DLO
skeleton, arrange the segments into an ordered path, and finally fit a
B-spline into it. Experiments show that our solution outperforms the State-of-
the-Art approaches in DLO’s shape reconstruction accuracy and algorithm
running time and can handle challenging scenarios such as severe occlusions,
self-intersections, and multiple DLOs in a single image.

##  I Introduction

Deformable Linear Objects (DLOs) are a class of objects that are characterized
by two main features: deformability, which refers to the fact that the object
is not a rigid body and its geometry can change, and linearity, which stands
for the fact that the object is elongated and the ratio of its length to its
width is substantial [1]. Such objects are ubiquitous both in everyday life
and in industry, where one can find ropes, cables, pipes, sutures, etc. While
the manipulation of rigid bodies is already solved for a wide range of objects
[2], manipulating DLOs is still unsolved even for everyday objects such as
cables and hoses. Due to the ubiquity of the DLOs, manipulating them poses a
complex and vital challenge, which has been in the scope of researchers for
over three decades [3]. The interest in this topic has grown over the last few
years, as the automatic wiring harness assembly is crucial for car
manufacturers [4], as well as automatic completion of surgical sutures, which
could help surgeons [5]. To perform such tasks autonomously, robotic
manipulators need to perceive the configuration of the manipulated object, as
this is crucial for calculating the adequate control signal. Achieving this
requires accurate and fast DLO tracking abilities. However, state-of-the-art
DLO tracking algorithms are relatively slow and do not meet the time
requirements of the control systems. In addition, they can not properly handle
manipulation sequences that contain occlusions [6] and self-intersections [7],
or make many assumptions about the model of the tracked object [8, 9].

Figure 1: Using the proposed DLO tracking algorithm, one can transform the DLO
mask into a low-dimensional B-spline representation in less than
$40\text{\,}\mathrm{ms}$.

This paper proposes a fast, non-iterative method for estimating a DLO’s shape
using a walk through object’s mask and B-spline regression. The proposed
algorithm takes as an input the mask of the DLO and returns a sequence of
control points of the B-spline curve that approximates the shape of the
tracked DLO. Our solution can deterministically identify the shape of a DLO on
the HD image within $40\text{\,}\mathrm{ms}$ while handling non-trivial
scenarios, like occlusions, self-intersections, and multiple DLOs in the
scene. The general scheme of the proposed approach is presented in Figure 1.

The main contribution of this work is twofold:

  * •

a novel deterministic fast DLO tracking algorithm, which can handle
occlusions, self-intersections, and multiple DLOs in the scene while requiring
no prior knowledge about the tracked DLO and is faster and more accurate than
State-of-the-Art solutions for assumed quality of the output shape,

  * •

dataset of real and artificial 2D and 3D videos and images of several
different DLOs, on which we performed a verification of the proposed method
and which we share with the community for objective performance evaluation and
to encourage the development of real-time DLO
tracking111https://github.com/PPI-PUT/cable_observer/tree/master.

##  II Related Work

###  II-A DLO representation

In the literature, there are several ways to represent the geometric shape of
the DLO. The most straightforward one is representing it as a sequence of
points [10, 11]. However, more complex models are usually necessary for
accurate cable modeling and tracking, like a B-spline model with multiple
chained random matrices, proposed in [6]. A similar approach, but using Bezier
curves and rectangle chains, was proposed in [12], while in [13] NURBS curves
were used. In our research, we use a B-spline representation (similar to the
one used in [12, 13]) as it is flexible and enables one to accurately track
the shape of a generic DLO while being compact, relatively easy, and cheap to
work with. Using this representation, one can build more complex models, which
consider the kinematics and dynamics of the DLO [14, 15].

###  II-B DLO tracking

DLO tracking requires transforming the data gathered with sensors into the
chosen representation. While there are attempts to use data from tactile
sensors [16], the most successful way to perceive the DLO shape is to use
vision and depth sensors. One of the most straightforward approaches to DLO
shape tracking is to use the fiducial markers located along the DLO, and track
them [11] or use them to estimate the shape of a DLO [17]. A similar approach
was presented in [18], where colors denote consecutive rope segments. The most
common approach is to create a model of the DLO and use images or point clouds
as measurements to modify its parameters and track the object deformation
iteratively. One of the examples of this approach is the modified expectation-
maximization algorithm (EM), proposed in [19], which is used to update the
predefined DLO model based on the registered deformations and simulation in
the physics engine. Similarly, in [8], the FEM methods were used to track the
deformation of the predefined model. Whereas, in [9], a Structure Preserved
Registration algorithm with the object represented as a Mixture of Gaussians
was used. Authors of [12] performed DLO tracking using the Recursive Bayesian
Estimator on the Spatial Distribution Model, built with the Bezier curve and
the chain of rectangles. Due to the iterative and often probabilistic
character of the model updates, these methods usually have problems tracking
rapidly deforming objects and require an appropriate model and accurate
initialization. To mitigate the slow initialization problem, authors of [6]
used the Euclidean minimum spanning tree and the Breadth-first search method
to speed up initialization. However, obtaining the DLO shape estimate still
takes hundreds of milliseconds. A much faster EM-based tracking approach,
which utilizes a coherent point drift method extended with some geometric-
based regularization and physically and geometrically inspired constraints,
was presented in [7]. The instance segmentation method for multiple DLOs,
which also can serve for tracking, was initially proposed in [20] and extended
using Deep Learning solutions in [21] and [22].

The solution presented in this paper utilizes a similar idea to the one
presented in [21, 22]. However, using skeletons instead of the super-pixel
graphs reduces the computational complexity [21], and the lack of Deep
Learning in our solution facilitates better generalization without sacrificing
performance [21, 22]. In our work, we do not try to model the DLO, but
instead, quickly provide a compact representation of the DLO state, that is
consistent and is trackable between frames. Thus, the proposed method can aid
the existing model-based methods with fast and accurate structured
measurements of the system state.

##  III DLO Tracking

###  III-A Problem Formulation

The problem considered in this paper is to track the DLO on the video
sequence. By tracking, we understand transforming consecutive video frames of
the DLO’s binary mask, obtained from the selected segmentation algorithm, into
a 1D curve resembling the object’s shape, which representation should be
consistent between frames. In this paper, we will not consider the image
segmentation problem similarly to [6, 7, 19]. But instead, we will focus on
shape tracking only, with the assumption that for homogeneously colored
cables, the mask is given by any color-based segmentation algorithm, or in
more challenging scenarios, state-of-the-art deep learning method [21] is
used.

###  III-B Proposed Method

In this section, we introduce our proposed novel approach to fast tracking of
DLO, called DLOFTBs, which by using the walks on the DLO mask’s skeleton,
enables rapid fitting of the B-spline curve into the masked image of the DLO.
The general scheme of the proposed algorithm is presented in Figure 2. To
transform the mask image into a B-spline curve, 4 main processing steps are
made: (i) morphological open & skeletonization, (ii) walk along the skeleton
segments, (iii) filtering and ordering of segments, and finally, (iv) B-spline
fitting. In the following subsections, we will describe each of these steps in
detail.

Figure 2: The general scheme of DLOFTBs. The mask image is transformed through
several processing stages to obtain a B-spline representation of its shape.

####  III-B1 Morphological open & skeletonization

The first operation we perform on the mask of the DLO is a $3\times 3$ (the
smallest possible) morphological open. We used it to remove some false
positive pixels, which are common because of imperfect segmentation. After
that, one of the essential steps in mask processing is performed –
skeletonization [23]. This operation takes the mask image as an input and
creates its skeleton, i.e., a thin version of the mask, which lies in the
geometric centers of the DLO segments, preserves its topology, and reduces its
width to a single pixel. This significantly reduces the amount of information
about the pixels representing the DLO while preserving the crucial information
encoded in central pixels along the DLO. Moreover, using the skeleton, one can
easily find the crucial parts of the DLO mask, such as segment endpoints –
pixels with only one neighbor or branching – pixels with more than two
neighbors. While the segment endpoints will constitute starting points for the
walks on segments, the branching points are crucial while performing a walk,
as they require the walker to choose one of several possible paths. To avoid
this inconvenience, we propose removing branching points and postponing the
decision to make connections between segments for further processing. By doing
so, we can simplify the segment walk algorithm considerably.

####  III-B2 Walk algorithm

Having the skeleton prepared and segment endpoints determined, we can perform
a walk along each segment. To do so, we start from a random segment endpoint
and go pixel by pixel till the end of the segment, collecting the subsequent
pixel coordinates. Such traversing is always possible and unambiguous, as we
removed all pixels with more than two neighbors in the previous step. After
each walk, we remove two points from the set of endpoints that were the
segment’s beginning and end. Next, we draw another segment endpoint and
perform a walk, which repeats until the end of the segment endpoints. As a
result, we obtain a set of paths i.e., ordered lists of pixels representing
all segments.

####  III-B3 Filtering and ordering of segments

In this step, we first filter out segments shorter than $p$ pixels, which are
likely to represent some artifacts of the mask or resulting from the
skeletonization procedure. While this approach may also result in removing a
short part of the actual DLO, it will not affect the resultant path
significantly, as it will be treated as occlusion and handled by our algorithm
at the next stage.

In order to fit a B-spline effectively into a set of segments, we need to
order them. As a result of the previous processing step, we have an unordered
set of ordered lists of pixels. To order them, we need to find segment
endpoint pairs that will most likely connect to each other. While there are
many possible criteria and algorithms for deciding about connections, we
decided to use a criterion that takes into account both the distance and
orientation of the endpoints and is defined by

$J=mJ_{d}+(1-m)J_{o},$ (1)

where $J_{d}$ is a euclidean distance between segment endpoints, $J_{o}$ is a
criterion related to the mutual orientation of the segment endpoints, and
$m\in[0;1]$ is a linear mixing factor. While the definition of $J_{d}$ is
rather straightforward, the exact formula of the $J_{o}$ is given by

$J_{d}=|\pi-\phi_{1}-\phi_{2}|,$ (2)

where $\phi_{1},\phi_{2}$ are approximated orientations of the segment
endpoints.

Using the criterion $J$ (1), one can decide about the pairs of the segment
endpoints. The most accurate solution would be to check for all possible
pairing schemes and find the one with the lowest $J$. However, it is also the
most computationally expensive one, as it requires checking even
$(2s-1)(2s-3)\ldots 1$ pairings, where $s$ is the number of segments. To limit
the computational burden, we decided to use a potentially less accurate but
much faster approach – a greedy one. Thus, we need to choose at most $s-1$
connections out of $s(2s-1)$ pairs of endpoints, considering the already taken
endpoints. Note that we don’t want to make highly improbable connections.
Therefore, we introduce a threshold $J_{th}$ and consider only the connections
for which criterion $J<J_{th}$. This enables us to track a single cable
robustly and detect and track multiple DLOs at once. Finally, all detected
sequences of segments are separately passed to the B-spline fitting phase,
described in the next point. B-spline curves provide a compact representation
that can be used to identify DLO instances based on the representation
continuity between frames.

####  III-B4 B-spline fitting

To fit the B-spline to the sequence of segments, we need an argument for the
B-spline, i.e., the vector $t$ of the relative position of the pixels on the
curve we want to define. To do so, we calculate the distance along the
segments and euclidean distances between segments and concatenate them into a
single vector, the cumulative sum of which serves as the B-spline argument
$t$. Using the Euclidean distance between segments, we introduce an estimate
of the distance along the DLO (we do not have access to the true one, as the
parts of a DLO are occluded). This procedure prevents sudden changes in the
pixel’s positions in terms of the B-spline argument $t$.

Moreover, we need to define the number and positions of knots. In the proposed
solution, we defined knots as a sequence of $k$ equidistant, in terms of the
element number, elements of the vector $t$, as it will ensure that the
Schonenberg-Whitney conditions [24] are met.

Finally, one can fit two dimensional B-spline using the prepared argument
vector $t$, knots, and $x$ and $y$ coordinates of the ordered pixels. We used
cubic splines, as higher continuity is unnecessary for the considered problem.

####  III-B5 3D data

Even though the proposed DLO tracking algorithm is meant to work on images, it
can be easily extended to work for the 3D data obtained from the RGBD sensor.
In this case, we deal with the mask in the same way as for the 2D case till
the moment of the B-spline fitting. Given a sequence of segments in the 2D
space, we augment it with the corresponding depth coordinates and then perform
the B-spline fitting. Thus, we obtain three dimensional B-spline representing
the shape of the cable with respect to the curve length estimate.

##  IV Experiments

To perform all experiments, we used a single core of the Intel Core i7-9750H
CPU and following, heuristically chosen single set of parameters of our
algorithm $m=0.05$, $p=10$, and $k=25$, which are the mixing factor of
segments connection criteria, segments length threshold, and the number of
knots.

###  IV-A Datasets

To evaluate the proposed cable tracking method (DLOFTBs), we conducted several
experiments, which show the performance of the proposed algorithm on 4
datasets:

####  IV-A1 RGB real

7 sequences of RGB images ($\approx 900$ frames in total), collected with the
Intel RealSense D435 camera, of a single cable being manipulated by two UR3
manipulators.

####  IV-A2 RGBD real

10 sequences of RGBD images ($\approx 2500$ frames in total), collected with
the Kinect Azure, of the single cable being manipulated by a human.

####  IV-A3 RGBD artificial

5 sequences of the artificially created RGBD images ($\approx 1400$ frames in
total), generated from a reference curve evolving in time. This dataset allows
us to compare directly to the reference curve instead to mask.

####  IV-A4 Ariadne+

The test set, taken from [21], consists of 62 images of multiple cables. We
enriched this dataset with manual annotations of the cable shapes to
facilitate direct comparison between curve shapes.

###  IV-B Performance criteria

Assessing the quality of the DLO shape tracking is not a trivial task [25],
especially when the only ground truth data available is the mask of the DLO
(datasets 1 and 2). For dataset 1 and dataset 2, we use two Mean Minimal
Distance (MMD) criteria, which build upon the ideas of Modified Hausdorff
Distance [26] and are defined by

$\mathcal{L}_{1}=\operatorname{MMD}(\mathcal{M},\mathcal{C}_{d})\quad\text{and}\quad\mathcal{L}_{2}=\operatorname{MMD}(\mathcal{C}_{d},\mathcal{M}),$
(3)

where

$\operatorname{MMD}(X,Y)=\frac{1}{|X|}\sum_{x\in X}\min_{y\in Y}d(x,y),$ (4)

where $d(x,y)$ is a Euclidean distance between $x$ and $y$, $\mathcal{M}$ is a
set of pixels belonging to a mask, while $\mathcal{C}_{d}$ is a set of points
on the predicted curve $\mathcal{C}$.

In turn, for dataset 3 and dataset 4 we have access to the mathematical curve
representing the reference shape $\mathcal{C}_{r}$. Therefore, we can
formulate a much more accurate measure of the performance, which builds upon
the Fréchet distance [27], and is defined by

$\mathcal{L}_{3}(\mathcal{C}_{d},\mathcal{C}_{r_{d}})=\frac{F(\mathcal{C}_{d},\mathcal{C}_{r_{d}})+F(\mathcal{C}_{r_{d}},\mathcal{C}_{d})}{2},$
(5)

where $\mathcal{C}_{r_{d}}$ is a discretized version of the reference path,
and where

$\begin{split}F(X,Y)=\frac{1}{|X|}\sum_{i=0}^{|X|-1}\min_{w\in[0;1]}d(&X(i),(1-w)Y(k(i))\\\
&+wY(k(i)+1)),\end{split}$ (6)

where $k(i)$ satisfies $D_{Y}(k(i))\leq D_{X}(i)\leq D_{Y}(k(i)+1)$ and is
monotonically non-decreasing, where $D_{X}(i)$ is a normalized distance along
$X$ curve at $i$-th discretization point. This function allows for fair
alignment of curves despite possible differences in parameterization.

Figure 3: Comparison of 2D DLO tracking algorithms. Only our approach was able
to handle occlusions and self-intersections of the tracked cable.

###  IV-C 2D videos of a single cable

TABLE I: Performance of the proposed DLO tracker on several 2D videos of dual-arm manipulation. Algorithm | Scenario | 0 | 1 | 2 | 3 | 4 | 5 | 6
---|---|---|---|---|---|---|---|---
DLOFTBs |  $\mathcal{L}_{1}$ [px] | 4.82$\pm$0.05 | 6.15$\pm$0.13 | 2.45$\pm$0.09 | 2.88$\pm$0.17 | 4.97$\pm$0.30 | 2.92$\pm$0.08 | 4.45$\pm$0.04
$\mathcal{L}_{2}$ [px] | 0.88$\pm$2.35 | 0.39$\pm$0.12 | 1.67$\pm$3.13 | 7.08$\pm$14.58 | 0.56$\pm$0.03 | 0.72$\pm$0.07 | 0.99$\pm$0.02
Time [ms] | 38.2$\pm$6.4 | 34.8$\pm$4.4 | 30.0$\pm$5.2 | 33.2$\pm$10.0 | 39.5$\pm$4.0 | 26.0$\pm$2.0 | 35.1$\pm$2.0
Ariadne+ |  $\mathcal{L}_{1}$ [px] | 8.03$\pm$4.38 | 12.45$\pm$16.80 | 30.01$\pm$32.57 | 29.55$\pm$0.64 | 54.85$\pm$71.67 | 117.60$\pm$38.23 | –
$\mathcal{L}_{2}$ [px] | 0.51$\pm$0.8 | 1.99$\pm$4.71 | 1.22$\pm$3.18 | 47.59$\pm$1.55 | 0.74$\pm$0.23 | 2.63$\pm$6.60 | –
Time [ms] | 973.9$\pm$35.3 | 956.0$\pm$61.3 | 974.2$\pm$30.5 | 935.5$\pm$37.0 | 962.5$\pm$31.0 | 923.3$\pm$30.9 | –
FastDLO |  $\mathcal{L}_{1}$ [px] | 9.17$\pm$12.8 | 8.98$\pm$10.32 | 29.3$\pm$33.2 | 29.1$\pm$47.5 | 177.6$\pm$16.6 | 173.7$\pm$6.5 | 171$\pm$13
$\mathcal{L}_{2}$ [px] | 0.36$\pm$0.01 | 0.37$\pm$0.01 | 0.36$\pm$0.01 | 0.36$\pm$0.02 | 0.37$\pm$0.01 | 0.36$\pm$0.01 | 0.36$\pm$0.02
Time [ms] | 86.3$\pm$6.3 | 97.6$\pm$10.2 | 62.2$\pm$6.5 | 64.9$\pm$9.5 | 96.4$\pm$9.1 | 60.8$\pm$9.0 | 88.3$\pm$3.6
| Frames |  |  |  |  |  |  |

In the first stage of the experimental evaluation, we evaluated DLOFTBs on RGB
real dataset (see Section IV-A1) , with masks generated using hue-based
segmentation, and compared it with Ariadne+ [21] and FastDLO [22] learned
approaches. We used cables with different widths and lengths and tested all
algorithms on challenging setups, shown in Table I, including self-
intersection (scenario 6) and occlusions (scenarios 2-6). Obtained results
show that the proposed algorithm achieves the most stable behavior and
outperforms all baselines in terms of criterion $\mathcal{L}_{1}$ and
processing time, and achieves similar results in terms of criterion
$\mathcal{L}_{2}$. Huge values of $\mathcal{L}_{1}$ for the baselines
indicate, that, unlike DLOFTBs, they are unable to cover the whole cable with
the predicted spline (extreme case is Ariadne+ which was unable to generate
any curve for scenario 6). Whereas, small values of $\mathcal{L}_{2}$ for
almost all cases, ensures that predicted splines do not cover empty areas. Our
method achieves a relatively big value of $\mathcal{L}_{2}$ only for scenario
3, in which large parts of the cable are outside the camera’s field of view,
therefore, even reasonable and plausible curves generated by the proposed
method results in the growth of $\mathcal{L}_{2}$. The behavior of the
algorithms for some sample challenging frames is presented in Figure 3. Even
though both baselines were provided with a very clean mask of the tracked
cable, they were unable to handle occlusions and self-intersections, whereas
DLOFTBs handled them perfectly.

TABLE II: Comparison of the DLOFTBs with CDCPD2 algorithm on several 3D videos of a human manipulating the cable. Scenario | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
---|---|---|---|---|---|---|---|---|---|---
CDCPD2 [7] | $\mathcal{L}_{1}$ | 6.26 | 7.1 | 6.21 | 5.73 | 15.6 | 5.49 | 6.03 | 5.79 | 19.0 | 11.19
$\mathcal{L}_{2}$ | 2.73 | 2.85 | 6.55 | 3.87 | 16.6 | 2.83 | 2.76 | 2.5 | 12.3 | 3.79
Time [ms] | 81 | 110 | 125 | 120 | 87 | 85 | 91 | 92 | 92 | 103
DLOFTBs | $\mathcal{L}_{1}$ | 5.05 | 5.31 | 4.41 | 4.5 | 4.07 | 3.79 | 4.69 | 4.51 | 4.79 | 5.23
$\mathcal{L}_{2}$ | 1.08 | 1.04 | 5.75 | 2.71 | 2.08 | 0.88 | 1.21 | 1.03 | 1.58 | 0.68
Time [ms] | 26 | 36 | 38 | 33 | 29 | 30 | 19 | 18 | 23 | 26
Sample frame |  |  |  |  |  |  |  |  |  |

###  IV-D 2D masks of multiple cables

Figure 4: Comparison of multiple DLOs tracking methods on Ariadne+ dataset.

In this experiment, we evaluated the ability of DLOFTBs to identify multiple
cables at once on the masked image and compared directly with Ariadne+ and
FastDLO algorithms [21, 22] on the augmented version of the Ariadne+ test set
(Section IV-A4) segmented using DeepLabV3+ network III for all algorithms. The
result of this comparison can be found in Table III. We outperformed Ariadne+
and FastDLO in terms of algorithm execution time, and the accuracy of the DLO
shape reconstruction, and scored second in the number of wrongly identified
DLOs. The relatively high number of redundant curves fitted by DLOFTBs is a
result of extremely noisy masks generated by DeepLabV3+ (see 3rd column of
Figure 4). In Figure 4 we present a qualitative analysis of algorithms
behavior on 3 challenging images. Ariande+ has severe problems with handling
complex backgrounds and bends at the intersections of cables, while FastDLO
cannot solve the intersection in the 2nd image properly and produces a wavy
shape for the left cable in the 1st image. In turn, DLOFTBs generates the most
accurate solutions for the first two images, however, if the mask is very
noisy (3rd image) it fits curves into linear false positives regions of the
mask.

TABLE III: Comparison of DLOFTBs and Ariadne+ algorithms on multiple cable detection benchmarks. Algorithm | $\mathcal{L}_{3}$ | # missing | # redundant | Time [ms]
---|---|---|---|---
Ariadne+ | 45.06 | 9 | 16 | 421.3
FastDLO | 51.55 | 3 | 75 | 64.3
DLOFTBs | 27.17 | 3 | 33 | 39.2

###  IV-E 3D video sequences

To accurately compare the proposed approach with another State-of-the-Art
method, we made our algorithm work with 3D data, for which the State-of-the-
Art CDCPD2 algorithm [7] was designed.

####  IV-E1 Real data

Figure 5: DLOFTBs (green) and CDCPD2 algorithm (red) on real-data 3D cable
tracking sequence. With the fast movement of the cable and insufficiently
large cable model updates, CDCPD2 could not track the moving cable. In
contrast, our approach accurately tracks the cable shape throughout the
sequence.

In our experiments, to accurately compare the precision of shape tracking, we
adjusted the video frame rate to enable each algorithm to process it at its
own pace and reported the times needed to process a single frame.Furthermore,
because the performance of the CDCPD2 method is strongly related to the cable
length estimate, we tested it for several different lengths for each scenario
and reported only the best result, while our algorithm required no parameter
tuning.

In Table II we present mean values of the $\mathcal{L}_{1}$ and
$\mathcal{L}_{2}$ errors and mean algorithm running times for 10 scenarios of
cable being manipulated by a human, and sample frames for each scenario from
the RGBD real dataset (see Section IV-A2). DLOFTB achieves lower errors than
CDCPD2 for all considered scenarios and criteria, and its running times are
about 3 times shorter. While for many scenarios values of the criteria are
rather comparable, there are some cases where the proposed approach
outperforms the CDCPD2 by a large margin (scenarios 4, 8, 9). In these cases,
the CDCPD2 algorithm lost the track of the cable shape due to the fast
movements of the cable (scenarios 8 and 9) or the complexity of the initial
shape (scenario 4).

In Figure 5 we present a sample tracking sequence, in which our algorithm is
able to keep track of the cable movements and deformations. At the same time,
for CDCPD2 the changes are too significant to be possible to follow. Moreover,
for the last images in the sequence, CDCPD2 produces a wavy shape, which does
not reflect the actual cable shape but does not increase the performance error
measures significantly.

####  IV-E2 Artificial data

To expose the aforementioned types of errors and accurately measure the
quality of tracking, we need to utilize the $\mathcal{L}_{3}$ criterion.To do
so, we used RGBD artificial dataset (see Section IV-A3), which also includes
challenging cases like high cable curvature (scenarios 0, 1), self-
intersections (scenarios 1, 2) and rapid cable moves (scenarios 3, 4).

The results of this comparison are presented in Table IV. Also, in this
experiment, our proposed approach outperforms the CDCPD2 algorithm. However,
the use of the more accurate criterion emphasized the differences between
compared methods. DLOFTB achieves mean $\mathcal{L}_{3}$ values that are from
6 to 20 times smaller than those achieved by CDCPD2. Minimal mean values of
$\mathcal{L}_{3}$ show that our approach is, on average, more accurate than
the best predictions made by the CDCPD2 in 4 out of 5 scenarios. Moreover,
maximal mean values show that throughout 3 out of 5 scenarios, DLOFTBs does
not produce any significantly wrong measurements (max mean
$\mathcal{L}_{3}>10$), while CDCPD2 does so for all scenarios. In Figure 6 we
present a part of the scenario 2 in which cable was recovering from the self-
intersection. Our algorithm was able to accurately track the cable throughout
the whole process. In contrast, the CDCPD2 crushed when the cable was
occluding itself a moment before the untangling and lost track for the rest of
the sequence.

TABLE IV: Comparison of DLOFTBs and CDCPD2 algorithms on several artificially generated 3D cable manipulation scenarios. Scenario | 0 | 1 | 2 | 3 | 4
---|---|---|---|---|---
CDCPD2 | mean $\mathcal{L}_{3}$ | 7.94 | 10.62 | 26.8 | 23.9 | 30.4
max mean $\mathcal{L}_{3}$ | 128 | 75 | 198 | 82 | 100
min mean $\mathcal{L}_{3}$ | 1.96 | 2.96 | 2.02 | 2.82 | 2.48
DLOFTBs | mean $\mathcal{L}_{3}$ | 1.59 | 4.22 | 1.99 | 2.42 | 2.47
max mean $\mathcal{L}_{3}$ | 2.6 | 38.1 | 47.7 | 5.75 | 6.91
min mean $\mathcal{L}_{3}$ | 1.23 | 1.57 | 1.1 | 1.48 | 1.34
Sample frame |  |  |  |  |
Figure 6: DLOFTBs (green) and CDCPD2 algorithm (red) on artificially generated
data of 3D cable tracking sequence. In the complex case of deforming the cable
from the self-intersection into the basic shape, our approach accurately
tracks the deformation throughout the whole sequence. In contrast, the CDCPD2
started with accurate tracking but degraded significantly after the last
moment when the cable was self-intersecting.

##  V Conclusions

This paper proposes a novel approach to DLO tracking on 2D and 3D images and
videos called DLOFTBs. Using a segmented mask of the cable, we can precisely
fit a B-spline representation of its shape within tens of milliseconds. The
experimental analysis showed that DLOFTB is accurate and can handle tedious
cases like occlusions, self-intersections, or even multiple DLOs at one time.
Moreover, it outperforms the State-of-the-Art DLO tracking algorithms CDCPD2
[7], Ariadne+ [21], and FastDLO [22] in all considered scenarios both in terms
of the quality of tracking, identification of multiple cables, and algorithm
running time. Moreover, the proposed solution is able to solve all
aforementioned problems with a single set of parameters and does not require
any training. Thus it does not depend on the training data, and, unlike the
CDCPD2, does not need any prior information about the DLO.

Our method was extensively tested against algorithmic and learned methods. The
weakness of the approaches that utilize learning is that they have substantial
problems with generalization and are not working with the data outside the
training set distribution. Our approach is not suffering from this issue, so
it is better suitable for robotics. We claim that there is still some space
for non-deep-learning approaches, which are better in generalization and are
fully explainable.

## References

  * [1] J. Sanchez, J.-A. Corrales, B.-C. Bouzgarrou, and Y. Mezouar, “Robotic manipulation and sensing of deformable objects in domestic and industrial applications: a survey,” _The Int. J. of Rob. Res._ , vol. 37, no. 7, pp. 688–716, 2018.
  * [2] A. Billard and D. Kragic, “Trends and challenges in robot manipulation,” _Science_ , vol. 364, no. 6446, p. 8414, 2019.
  * [3] M. Inaba and H. Inoue, “Rope handling by a robot with visual feedback,” _Advanced Rob._ , vol. 2, no. 1, pp. 39–54, 1987.
  * [4] P. Kicki, M. Bednarek, P. Lembicz, G. Mierzwiak, A. Szymko, M. Kraft, and K. Walas, “Tell me, what do you see?—interpretable classification of wiring harness branches with deep neural networks,” _Sensors_ , vol. 21, no. 13, 2021.
  * [5] S. Sen, A. Garg, D. V. Gealy, S. McKinley, Y. Jen, and K. Goldberg, “Automating multi-throw multilateral surgical suturing with a mechanical needle guide and sequential convex optimization,” in _2016 IEEE Int. Conf. on Rob. and Aut. (ICRA)_ , 2016, pp. 4178–4185.
  * [6] G. Yao, R. Saltus, and A. Dani, “Shape estimation for elongated deformable object using B-spline chained multiple random matrices model,” _Int. J. of Intell. Rob. and Appl._ , vol. 4, no. 4, pp. 429–440, Dec 2020.
  * [7] Y. Wang, D. McConachie, and D. Berenson, “Tracking partially-occluded deformable objects while enforcing geometric constraints,” in _IEEE Int. Conf. on Rob. and Aut. (ICRA)_ , 2021, pp. 14 199–14 205.
  * [8] A. Petit, V. Lippiello, and B. Siciliano, “Real-time tracking of 3d elastic objects with an rgb-d sensor,” in _2015 IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS)_ , 2015, pp. 3914–3921.
  * [9] T. Tang and M. Tomizuka, “Track deformable objects from point clouds with structure preserved registration,” _Int. J. of Rob. Res._ , 2019.
  * [10] H. Han, G. Paul, and T. Matsubara, “Model-based reinforcement learning approach for deformable linear object manipulation,” in _2017 13th IEEE Conf. on Aut. Sci. and Eng. (CASE)_ , 2017, pp. 750–755.
  * [11] Y. Lai, J. Poon, G. Paul, H. Han, and T. Matsubara, “Probabilistic pose estimation of deformable linear objects,” in _2018 IEEE 14th Int. Conf. on Aut. Sci. and Eng. (CASE)_ , 2018, pp. 471–476.
  * [12] A. Zea, F. Faion, and U. D. Hanebeck, “Tracking elongated extended objects using splines,” in _2016 19th Int. Conf. on Information Fusion (FUSION)_ , 2016, pp. 612–619.
  * [13] R. C. Jackson, R. Yuan, D. Chow, W. Newman, and M. Çavuşoğlu, “Real-time visual tracking of dynamic surgical suture threads,” _IEEE Trans. on Aut. Sci. and Eng._ , vol. 15, no. 3, pp. 1078–1090, 2018.
  * [14] G. Palli, “Model-based manipulation of deformable linear objects by multivariate dynamic splines,” in _2020 IEEE Conf. on Industrial Cyberphysical Systems (ICPS)_ , vol. 1, 2020, pp. 520–525.
  * [15] J. Spillmann and M. Teschner, “Corde: Cosserat rod elements for the dynamic simulation of one-dimensional elastic objects,” in _Proceedings of the 2007 ACM SIGGRAPH/Eurographics Symposium on Computer Animation_ , ser. SCA ’07, 2007, p. 63–72.
  * [16] J. Sanchez, C. M. Mateo, J. A. Corrales, B. Bouzgarrou, and Y. Mezouar, “Online shape estimation based on tactile sensing and deformation modeling for robot manipulation,” in _2018 IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS)_ , 2018, pp. 504–511.
  * [17] A. Borum, D. Matthews, and T. Bretl, “State estimation and tracking of deforming planar elastic rods,” in _2014 IEEE Int. Conf. on Rob. and Aut. (ICRA)_ , 2014, pp. 4127–4132.
  * [18] W. H. Lui and A. Saxena, “Tangled: Learning to untangle ropes with rgb-d perception,” in _2013 IEEE/RSJ Int. Conf. on Intelligent Robots and Systems_ , 2013, pp. 837–844.
  * [19] J. Schulman, A. Lee, J. Ho, and P. Abbeel, “Tracking deformable objects with point clouds,” in _2013 IEEE Int. Conf. on Rob. and Aut._ , 2013, pp. 1130–1137.
  * [20] D. D. Gregorio, G. Palli, and L. di Stefano, “Let’s take a walk on superpixels graphs: Deformable linear objects segmentation and model estimation,” in _ACCV_ , 2018, pp. 662–677.
  * [21] A. Caporali, R. Zanella, D. De Gregorio, and G. Palli, “Ariadne+: Deep learning-based augmented framework for the instance segmentation of wires,” _IEEE Transactions on Industrial Informatics_ , pp. 1–1, 2022.
  * [22] A. Caporali, K. Galassi, R. Zanella, and G. Palli, “Fastdlo: Fast deformable linear objects instance segmentation,” _IEEE Robotics and Automation Letters_ , vol. 7, no. 4, pp. 9075–9082, 2022.
  * [23] T. Lee, R. Kashyap, and C. Chu, “Building skeleton models via 3-d medial surface axis thinning algorithms,” _CVGIP: Graphical Models and Image Processing_ , vol. 56, no. 6, pp. 462–478, 1994.
  * [24] I. J. Schoenberg and A. Whitney, “On polya frequency function. iii. the positivity of translation determinants with an application to the interpolation problem by spline curves,” _Trans. of the American Mathematical Society_ , vol. 74, no. 2, pp. 246–259, 1953.
  * [25] R. Veltkamp, “Shape matching: similarity measures and algorithms,” in _Proceedings International Conference on Shape Modeling and Applications_ , 2001, pp. 188–197.
  * [26] M. Dubuisson and A. Jain, “A modified hausdorff distance for object matching,” in _Int. Conf. on Patt. Recog._ , vol. 1, 1994, pp. 566–568.
  * [27] M. Fréchet, “Sur quelques points du calcul fonctionnel,” _Rendiconti del Circolo Matematico di Palermo (1884-1940)_ , vol. 22, pp. 1–72.


# Calculation of Fission Fragment Yields for thermal neutron reaction of 239Pu

Futoshi Minato

###### Abstract

Fission fragment yield evaluation in the past has been done mainly by
considering independent and cumulative fission yields. In addition to them,
the fission fragment yields are related to various observables such as total
kinetic energy, prompt fission neutron, decay heats, etc. Various improvements
were carried out in the fission fragment yield evaluation of JENDL-5 [2],
however it did not consider correlations between such fission observables and
fragment yields. A new evaluation including fission observables is thus
required for next generation of evaluated data. We recently developed a new
calculation system using CCONE code to calculate fission fragment yields. This
calculation system enables us to compare various fission observables with the
experimental data simultaneously. In this work, we calculated thermal-induced
fission of 239Pu. We present the result of prompt fission neutrons, decay
heats, and delayed neutrons.

##  1 Introduction

Fission is a phenomenon that generates various by-products in addition to
fission fragments such as prompt neutrons (PN), decay heats (DH), and delayed
neutrons (DN). The number of PN is also concerned with excitation energies of
fragments, which are dependent on total kinetic energies (TKE) of fragments.
It is desirable to prepare evaluated data that have correlations between those
fission observables and fragment yields. In JENDL-5 [2] fission fragment yield
data are newly evaluated, where several improvements in spin-parity states,
isomers, and shell corrections have been done successfully. However,
correlations between the fission observables and fragment yields were not
considered when JENDL-5 was made.

We recently developed a new calculation system [3] for fission fragment yields
using CCONE [1]. Within the framework in CCONE, one can estimate fission
fragment yields and fission observables and compare them with the experimental
data simultaneously. The evaluation of thermal neutron-induced fission on 235U
was carried out in Ref. [3]. We recently carried out the calculation of
fission fragment yields of thermal neutron-induced fission on 239Pu. We will
present our results in this paper.

##  2 Formalism

The calculation method for fission fragment yield of 239Pu is almost the same
as that of 235U [3]. There are some characteristic points that are different
from 235U and we will illustrate them mainly in this paper.

The main difference is the pre-neutron emission mass yields (PFY). They are
approximated by a sum of four Gaussians

$Y(A)=N_{1}Y_{1}(A)+N_{2}Y_{2}(A)$ (1)

with

$Y_{i}(A)=\frac{1}{\sqrt{2\pi}\sigma_{i}}\left\\{\exp\left(-\frac{(A-\mu_{i}/2)^{2}}{2\sigma_{i}^{2}}\right)+\exp\left(-\frac{(A-(A_{c}-\mu_{i}/2))^{2}}{2\sigma_{i}^{2}}\right)\right\\}$
(2)

for $i=1,2$. $A_{h}$ and $A_{c}$ are the mass of a heavy fragment and a
compound nucleus, respectively. The normalization constants $N_{i}$ in Eq. (1)
$\mu_{i},\sigma_{i}$ in Eq. (2) are determined from experimental data (Table
1) via the least square fitting. We obtained
$N_{1}=0.21,\mu_{1}=14.44,\sigma_{1}=3.593,N_{2}=0.79,\mu_{2}=20.60,$ and
$\sigma_{2}=6.299$. The result is shown in the left panel of Fig. 1 together
with experimental data.

Table 1: Experimental data used for the parameter search.

PFY |  [6], [7], [8], [9], [10], [11], [12] [13], [14], [15]
---|---
TKE |  [16], [7], [8], [9], [12]
IFY |  [17], [18], [19], [20], [21], [22]
CFY | [20]

PG | [23]
---|---
DN | [32]
PN |  [12], [24], [25], [26], [27]
DH |  [28], [29], [30] [31]

Charge distributions are approximated by the $Z_{p}$-model [4] with
modifications of the most probable atomic number $Z_{p}(A)$ and the standard
deviation $\sigma_{p}(A)$ in the range of $64\leq A\leq 176$:

$C(A,Z)=\int_{Z-0.5}^{Z+0.5}\frac{1}{\sqrt{2\pi}\sigma_{p}(A)}\exp\left(-\frac{(Z^{\prime}-Z_{p}(A))^{2}}{2\sigma_{p}(A)^{2}}\right).$
(3)

The parameters of $Z_{p}(A)$ and $\sigma_{p}(A)$ are determined from the least
square fitting using the experimental data listed in Table 1. We used
independent fission yields (IFY), cumulative fission yields (CFY), the total
number of prompt $\gamma$-rays per fission (PG), PN, DH, and DN for the
parameter search.

Figure 1: (left) The PFY calculated from a sum of four Gaussians and
experimental data. (right) The TKE curves fitted by Eq. (4) (red solid line)
and experimental data.

A total kinetic energy (TKE) is also approximated by using the following
function, which is originally proposed by [36]:

${\rm
TKE}(A_{h})=\left(p_{0}-p_{1}A_{h}\right)\left(1-p_{2}\exp\left(-\left(A_{h}-\frac{A_{c}}{2}\right)^{2}p_{3}\right)\right)+\epsilon_{{\rm
TKE}}.$ (4)

The parameters $p_{i}$ $(i=0,1,2,3)$ are determined so as to reproduce
experimental data listed in Table 1. The results are
$p_{0}=220.4,p_{1}=1.050,p_{2}=0.1303$, and $p_{3}=29.77$. In Eq. (4),
$\epsilon_{\mathrm{TKE}}$ is introduced to satisfy the average TKE value of
experimental data $\overline{\mathrm{TKE}}=178$ MeV [11, 33, 34]. The result
of TKE using this parameter set is shown in the right panel of Fig. 1. A
fluctuation of TKE from Eq. (4) is considered by introducing a width parameter
$\sigma_{\mathrm{TKE}}(A_{l})=\sigma_{\mathrm{TKE}}(A_{h})=s_{0}-s_{1}\exp\left[-s_{2}\left(A_{h}-\frac{A_{c}}{2}\right)^{2}\right]$,
where $s_{i}$ $(i=0,1,2)$ are the parameters. They are also determined from
uncertainties of the experimental data, and we obtain
$s_{0}=5.520,s_{1}=5.750,s_{3}=5512$.

Excitation distributions of fission fragment yields are estimated as follows.
First, total excitation energy (${\rm TXE}$) is calculated by ${\rm
TXE}=E_{n}+S_{n}+M_{f}-(M_{l}+M_{h})-{\rm TKE}$, where $E_{n}$ is the incident
neutron energy, $S_{n}$ is neutron threshold of fissioning nucleus, and
$M_{f}$, $M_{l}$, and $M_{h}$ are the mass of fissioning nucleus, light
fragment, and heavy fragment, respectively. To sort ${\rm TXE}$ into two
fission fragments, we use an anisothermal model [35]

$R_{T}=\frac{T_{l}}{T_{h}}=\sqrt{\frac{a_{h}(U_{h})U_{l}}{a_{l}(U_{l})U_{h}}},$
(5)

where $U_{l,h}=E_{l,h}-\varDelta$ with $\varDelta$ being a correction energy
attributed from pairing correlations [37]. The function $a_{l,h}(U_{l,h})$ is
given by $a_{l,h}(U_{l,h})=a^{*}\left(1+E_{sh}\frac{1-e^{1-\gamma
U_{l,h}}}{U_{l,h}}\right)$, where $a^{*}$, $E_{sh}$, $\gamma$ are the
asymptotic level density parameter, the shell correction, and the shell
damping factor, respectively, and taken from Ref. [37]. The mean excitation
energies $E_{l,h}$ are estimated numerically from Eq. (5) with a condition of
$E_{l}+E_{h}=\mathrm{TXE}$. The excitation energy distributions are then
estimated by [39]

$G_{l,h}(E)=\frac{1}{\sqrt{2\pi}\sigma_{l,h}}\exp\left(-\frac{(E-E_{l,h})^{2}}{2\sigma_{l,h}^{2}}\right),$
(6)

where $\sigma_{l,h}=\frac{E_{l,h}}{\sqrt{E_{l}^{2}+E_{h}^{2}}}\sigma_{{\rm
TKE}}$. Odd-even effects of fission fragment yields are considered via $f_{z}$
and $f_{n}$ [38]. Fission fragment yields including spin-parity distributions
are then given by

$Y(A,Z,J^{\pi},{\rm
TKE})=\frac{1}{2}\frac{J+1/2}{2f_{s}^{2}\sigma^{2}}\exp\left(\frac{(J+1/2)^{2}}{2f_{s}^{2}\sigma^{2}(U)}\right)Y(A)C(A,Z)G_{l,h}(E)$
(7)

The parameters for $f_{s}=2.756$ in Eq. (7), odd-even effect parameters
$f_{z}=1.120$, $f_{n}=1.020$ and the scaling factor of asymptotic level
density parameter $f_{a}=0.6$ are adjusted by hand so that the calculated
delayed neutrons and prompt neutrons come closer to the experimental data.

##  3 Result

The result of neutron multiplicities as a function of fragment mass is shown
in the left panel of Fig. 2. The experimental data used for the parameter
search within the least square fitting are also shown. Our calculations
roughly reproduce the seesaw structure as found in the experimental data. In
this framework, the result of CCONE shows some deviations from the
experimental data for light fragments ($60\leq A\leq 120$), while it is
relatively in a good agreement with the experiments for heavy fragment sides
($135<A\leq 150$). The right panel of Fig 2 shows the delayed neutron yields
as a function of time after fission burst launched by instant neutron
irradiation. The present CCONE calculation is comparable to the evaluated data
of JENDL-5, which nicely reproduces the Keepin’s experimental data [32].

Figure 2 shows decay heats of $\beta$-rays and $\gamma$-rays. The present
framework of CCONE reasonably reproduces the experimental data both for
$\beta$ and $\gamma$-rays. In particular, this work improved the result of
$\gamma$ decay heat as compared to the evaluation of JENDL-5 which
overestimated around time after fission burst $t=80$ (s).

Figure 2: (Left) Calculated and experimental neutron multiplicities as a
function of fragment mass. (Right) Delayed neutron yields as a function of
time after fission burst. The result is shown together with the JENDL-5
evaluations.

Figure 3: $\beta$-ray (Left) and $\gamma$-ray (Right) decay heats as a
function of fission burst.

##  4 Summary

We calculated fission fragment yields of thermal neutron induced fission on
239Pu with a newly developed CCONE code system. The calculated result is
compared with experimental data and the evaluation of JENDL-5. We could obtain
a reasonable agreement with experimental data and found that the result is
comparable to JENDL-5 although some discrepancies from the experimental data
are found in neutron multiplicities. We will calculate fission fragment yields
of different systems using this CCONE code system.

## References

  * [1] Iwamoto O., Iwamoto N., Kunieda S., et al., The CCONE Code System and its Application to Nuclear Data Evaluation for Fission and Other Reactions. Nuclear Data Sheets 2016;131;259–288.
  * [2] Iwamoto O., Iwamoto N., Kunieda S., et al., Japanese evaluated nuclear data library version 5: JENDL-5. Journal of Nuclear Science and Technology, 2003;60;1–60.
  * [3] Minato F. and Iwamoto O., Fission Fragment Yields Of 236U$(n,f)$ Evaluated By The CCONE Code System, in preparation.
  * [4] Wahl A.C., Systematics of Fission-Product Yields, LANL, LA-13928 (2002).
  * [5] England T.R. and Rider B.F., Evaluation and Compilation of Fission Product Yields, Los Alamos National Laboratory, LA-UR-94-3106 (1994).
  * [6] Akimov N.I., Vorobeva V.G., Kabenin V.N., et al., Effect of Excitation Energy on Yields and Kinetic Energies of Fragments in Fission of Pu239 by Neutrons, Soviet J. Nucl. Phys. 1971;13;272.
  * [7] Geltenbort P., Connewein F. and Oed A., Precision measurements of mean kinetic energy release in thermal-neutron-induced fission of 233U, 235U and 239Pu, Conf. Nucl. Data f. Basic a. Appl.Sci., Santa Fe, Vol. 1 (1985), p.393.
  * [8] Franz-Josef Hambsch, Luca Demattè, Bax H., et al., Fission of 239Pu with resonance neutrons, J. Nucl. Sci. Technol. 2002;39;307-310.
  * [9] Nishio K., Nakagome Y., Kanno I., et al., Measurement of Fragment Mass Dependent Kinetic Energy and Neutron Multiplicity for Thermal Neutron Induced Fission of Plutonium-239, J. Nuc. Sci. Technol. 1995;32;404.
  * [10] Schillebeeckx P., Wagemans C., Deruytter A.J., et al., Comparative Study of the Fragments Mass and Energy Characteristics in the Spontaneous Fission of 238Pu, 240Pu and 242Pu and in the Thermal-Neutron-Induced Fission of 239Pu, Nucl. Phys. A 1992;545;623.
  * [11] Surin V.M., Sergachev A.I., Rezchikov N.I., et al., Yields and Kinetic Energies of Fragments in the Fission of U233 and Pu239 by 5.5- and 15-MeV Neutrons, Sov. J. Nucl. Phys. 1972;14;523.
  * [12] Tsuchiya C., Nakagome Y., Yamana H., et al., Simultaneous Measurement of Prompt Neutrons and Fission Fragments for 239Pu($n_{th},f$), J Nucl. Sci. Technol. 2000;37;941
  * [13] Wagemans C., Allaert E., Deruytter A., et al., Comparison of the energy and mass characteristics of the 239Pu($n_{th},f$) and the 240Pu($sf$) fragments, Phys. Rev. C 1984;30;218.
  * [14] Walsh R.L., Boldeman J.W. and Elcombe M.E., Viscosity effects at low excitation in the neutron fission of 239Pu, IAEA Symp. Phys. Chem. of Fission, Juelich, Vol.2 (1979), p.129.
  * [15] Walter F.J., Schmitt H.W. and Neiler J.H., Fragment Mass Distributions for Thermal-Neutron-Induced Fission of Pu239 and Pu241, Phys. Rev. 1964;133;B1500.
  * [16] Belyaev A.D., Bikbova Z.S., Kogan V.I., et al., Usmandiyarov A.M., Structure of the mass distributions of the products of thermal-neutron fission of 235U and 239Pu for a fixed energy of the fission products, J. Sci. Nucl. Phys. 1984;40;720.
  * [17] Guenther H., Siegert G., Ferguson R.L., et al. Fission-fragment charge distributions in thermal-neutron induced fission of 239Pu and 235U, Nucl. Phys. A 1972;196;401.
  * [18] Dubey S., Echler A., Egelhof P., et al., Precise 92Rb and 96Y yields for thermal-neutron-induced fission of 235U and 239,241Pu determined using calorimetric low-temperature detectors, Phys. Rev. C 2020;102;044602; Dubey S., Echler A., Egelhof P., et al., Isotopic distributions of thermal-neutron-induced fission fragments of near-symmetric fission of 239,241Pu determined using calorimetric low-temperature detectors, Phys. Rev. C 2021;104;034621.
  * [19] Srivastava A., Goswami A., Srivastava B.K., et al.,Fragment shell effect in low energy fission: Independent yields of technetium isotopes in the thermal-neutron-induced fission of 239Pu, Phys. Rev. C 1986;33;969.
  * [20] Naik H., Dange S.P., Singh R.J., et al., Post neutron mass yield distribution in the thermal neutron induced fission of 239Pu, Nucl. Sci. Eng. 2022;196;824.
  * [21] Bogdzel A.A., Gundorin N.A., Gohs U., et al., Peculiarities of Pu-239 fission by resonance neutrons, Conf.on Nucl. Data for Sci.and Technol., Juelich (1991), p.150.
  * [22] Fritze K., Mullen C.C.MC, Thode H.G., Absolute yields of the isotopes of xeon and krypton in the neutron fission of plutonium-239, Second Internat. At.En. Conf., Geneva 1958;15;436.
  * [23] Pleasonton F., Ferguson R.L., Schmitt H.W., Prompt Gamma Rays Emitted in the Thermal-Neutron-Induced Fission of 233U, 235U and 239Pu and the Spontaneous Fission of 252Cf, ORNL-4844 (1972), p.109.
  * [24] Basova B.G., Ryazanov D.K., Rabinovich A.D., et al., Neutrons emitted by fragments of the spontaneous fission of 252Cf and the fission of 239Pu by thermal neutrons, Soviet Atomic Energy 1979;46;282.
  * [25] Fraser J.S., Milton J.C.D., Nuclear Fission, Ann. Rev. Nucl. 1966;16;379.
  * [26] Batenkov O.A., Boykov G.A., Hambsch F.-J., et al., Prompt neutron emission in neutron-induced fission of 239Pu and 235U, AIP Conf. Proc. 769 (2005), pp.1003-1006
  * [27] Apalin V.F., Gritsyuk Yu.N., Kutikov I.E., et al., Neutron emission from U233, U235 and Pu239 fission fragments, Nucl.Phys. 1965;71;553.
  * [28] Akiyama M., An S., Measurement of fission product decay heat for fast reactor, Proc. of Int. Conf. on Nucl. Data for Science and Technol., Antwarp, Bergium (1982), p.237,
  * [29] Nguyen, H.V., et al., Decay Heat Measurements Following Neutron Fission of 235U and 239Pu, Proc. Int. Conf. on Nucl. Data for Science and Technol., Trieste, Italy (1997), p.835.
  * [30] Dickens J.K., Love T.A., McConnell J.W., et al., Fission Product Energy Release for Time following Thermal Neutron Fission of 235U between 2 and 14,000 seconds, Nucl. Sci. Eng. 1980;74;106-129.
  * [31] Johanson P.-I, Integral DEtermination of the Beta and Gamma Heat in Thermal-Neutron-Induced Fission of 235U and 239Pu, and of the Gamma Heat in Fast Fission of 238U, Proc. of Int. Conf. on Nucl. Data for Science and Technol., Mito, Japan, p.257 (1988).
  * [32] Keepin G.R., Wimett T.F., Zeigler R.K., Delayed neutrons from fissionable isotopes of uranium, plutonium and thorium, J. Nucl. Energy 1957;6;2-21.
  * [33] Vorobèva V.G., D’yachenko N.D., Kolosov N.P., et al., Effect of nucleonic composition of fissioning nuclei on the mean kinetic energy of the fragments, Sov. J. Nucl. Phys. 1974;19;489.
  * [34] Kolosov N.P., Kuzm̀inov B.D., Sergachev A.I., et al., Value of nu-bar from energy balance in U-233 and Pu-239 fission, Soviet Atomic Energy 1972;32;92.
  * [35] Kawano T., Talou P., Stetcu I., et al., Statistical and evaporation models for the neutron emission energy spectrum in the center-of-mass system from fission fragments, Nucl. Phys. A 2013;913;51-70.
  * [36] Okumura S., Kawano T., Jaffke P., et al., 235U(n,f)Independent fission product yield and isomeric ratio calculated with the statistical Hauser-Feshbach theory, J. Nucl. Sci. Technol. 2018;55;1009-1023.
  * [37] Mengoni A. and Nakajima Y., Fermi-Gas Model Parametrization of Nuclear Level Density, J. Nucl. Sci. Technol. 1994;31;151-162.
  * [38] Minato F., Neutron energy dependence of delayed neutron yields and its assessments, J. Nucl. Sci. Technol. 2018;55;1054-1064.
  * [39] Okumura S., Kawano T., Lovell A.E., et al., Energy dependent calculations of fission product, prompt, and delayed neutron yields for neutron induced fission on 235U, 238U, and 239Pu, J. of Nucl. Sci. Technol. 2021;59;96-109.

## Acknowledgments

This work is supported by JSPS KAKENHI Grant Number 21H01856 and MEXT
Innovative Nuclear Research and Development Program ”Fission product yields
predicted by machine learning technique at unmeasured energies and its
influence on reactor physics assessment” entrusted to the Tokyo Institute of
Technology.


# Simplified State Storage Rent for EVM Blockchains

Sergio Demian Lerner, Federico Jinich, Diego Masini, Shreemoy Mishra
{sergio, federico, dmasini<EMAIL_ADDRESS>

###### Abstract

Uncontrolled growth of blockchain state can adversely affect client
performance, decentralization and security. Previous attempts to introduce
duration-based state storage pricing or storage rent in Ethereum have stalled,
partly because of complexity. We present a new approach with finer granularity
to “spread” rent payments across peers. Our proposal shifts the burden of
state rent from ‘owners’ or contracts to transaction senders in a ‘quasi-
random’ manner. This proposal offers a simple path for initial adoption on
Ethereum Virtual Machine (EVM) compatible chains, and serve as a foundation to
address remaining challenges.

###### Index Terms:

state size, state storage rent, disk IO, DoS attacks, state expiration, state
caching

##  I Introduction

In public blockchains, we distinguish between two broad sets of blockchain
data. The first is the collection of cryptographically linked blocks, which
represents the core idea of blockchains as decentralized transaction
timestamping servers. The second data set is the current state of the system -
this is the information needed to actually execute a transaction.

###  I-A Blockchain State

In Bitcoin, the state is the set of all unspent transaction outputs (UTXOs).
Fully spent transaction outputs can be pruned to recover disk space. This is
so simple that some users claim Bitcoin has no state. The state is richer in
Turing complete smart contract platforms such as Ethereum. In Ethereum Virtual
Machine (EVM) compatible chains, state refers to data such as an account’s (or
smart contract’s) balance, nonce, a contract’s bytecode, or the data contained
in a contract’s storage cells. Transactions not only access state, they
transform it in the course of their execution. The stateroot in an EVM chain’s
block header is a cryptographic commitment of the cumulative, state-
transforming, impact of all transactions in that block.

Historical transaction data stored in blocks is not directly relevant for
processing transactions. But this history can be used to recreate any past
snapshot of the chain. Indeed, to re-execute an old transaction for validation
a client must first recreate the state of the system – exactly as it was –
when that transaction was initially processed and included in a block. This is
the reason why new nodes takes a long time to synchronize with the network.
For large chains such as Bitcoin and Ethereum, the initial block download and
subsequent verification can take days on consumer grade hardware. This has
lead to proposals to help jumpstart the process by offering new nodes a recent
snapshot or checkpoint of the state.

###  I-B The Problem with State Size Growth

In a recent conference talk [1], Péter Szilágyi, the lead developer of
geth111Go-ethereum or geth is the pervasive reference client implementation
for Ethereum in the Go programming langauge. remarked that Ethereum’s state
size growth places it on a “potential death trajectory”. While this may seem
dramatic, such concerns are neither new nor exaggerated. Ethereum co-founder
Vitalik Buterin [2] and other core developers have been raising these concerns
for a long time. Some consequences of continued expansion of the state include
physical limits on how fast Ethereum (and EVM chains) can process
transactions, and the inability of clients to sync with the blockchain.

In EVM compatible clients, state data are typically loaded to memory (RAM)
using tree-like data structures called tries. The concept of blockchain state
trie was introduced and popularized in Ethereum’s yellow paper [3]. The leaf
nodes in the trie contain actual state data for an account such as balance,
nonce, storage root, and _code hash_.

On disk (or external storage drives), clients save the state trie in simple
key-value datastores, most frequently using leveldb. Keys represent the path
or location of an account, or other state data, in the trie. Keys are
constructed as Keccak hashes (as hash-prefixes in some cases) of data
contained in a trie node, which helps avoid some types of DoS attacks.

When executing transactions, we expect blockchain clients to spend most of
their time manipulating relevant state data in memory, rather than reading
from or writing to disk. In the early days of Ethereum, the protocol’s
architects were more concerned about the costs of computing hashes than disk
input-output (IO) operations. This tradeoff is part of the reason why they
chose a hexary trie over a binary one. All else equal, a binary trie is
deeper, requiring more hash computations. Advances in computing power have
reduced the cost of computing hashes. With rapid growth in state size, disk IO
increasingly became the core bottleneck in executing transactions quickly.

If we want high transactions per second (TPS), then we must try and avoid
going to disk too often. This is only possible if clients try to keep as much
of the state as they can on RAM. Péter Szilágyi’s talk [1] mentioned earlier
has some striking observations. He estimates that the size of Ethereum’s state
is growing at the rate of about 20 GB per year. If we include the overhead of
internal nodes and housekeeping, this blows up to an increase of around about
40 GB per year.

It is not unusual for Ethereum core developers and professional node operators
to run clients on machines with 64 GBs of RAM, which is far beyond typical
user grade hardware. But even with such extraordinary amounts of RAM, there
are no guarantees that we can avoid going to disk entirely. As the state grows
faster relative to typical client memory, it becomes increasingly challenging
for new clients to sync with the chain. Today, most Ethereum users and
developers end up using API endpoints from hosted node service providers like
Infura or Alchemy. This may become the fate of other EVM chains as well, which
is not good for decentralization.

##  II Potential Solutions

There are two main proposals to avert the worst consequences of massive growth
in state size. The first is to introduce some form of state storage rent. This
is the path we follow in this article. The second route is a set of ideas
called state expiration, where we give up on the notion of clients storing
every piece of the current state, irrespective of how long it has remained
unused. These proposals call for evicting “stale” information - which creates
new problems. If some previously evicted or hibernated state is needed in the
future, how can we load that information reliably? Each proposal for dealing
with recovering ‘forgotten’ data attempts to handle the complex issues of
doing so with some proof of validity. We do not delve deeper into state
expiration any further. Our focus here is to present a proposal for duration
based pricing as incentives to manage state size.

###  II-A Early Proposals

The economic foundations for blockchain storage have never been very sound.
Bitcoin introduced a very simple transaction pricing system of Satoshis per
byte. This abstracted the true underlying cost of the P2P network such as
computation, storage, bandwidth, or energy. In this model, the age of an UTXO
had no impact on the fees while consuming it. This idea was carried over to
newer blockchains including Ethereum and lead to user expectations of the form
“pay once, store forever”.

After a while, it became apparent that such poor economics would lead to
unsustainable outcomes. Once the problem was apparent, proposals for time-
based pricing (i.e. state rent) were inevitable. Ethereum core developers,
including co-founder Vitalik Buterin, were early to recognize the value of
storage rent. There is nothing novel about charging a fee for the duration of
storing data. For instance, traditional cloud storage services such as AWS S3,
Dropbox, or Google Drive have almost always had time-based (typically monthly)
pricing from the start beyond free tiers).

In traditional cloud storage, users ”own” their data, and pay for storage
based on space and time. Things are less clear in blockchain state. Who should
pay rent for a popular library contract deployed by an anonymous user? Such
fair accounting and attribution of rent costs has always been problematic.
Many members of the community found the idea of rent incompatible with the
‘promise’ of smart contracts, once deployed, could be called forever. There
were several other complexities. For instance, if a preexisting contract was
suddenly liable to pay for its storage, then its account balance would change
in ways not anticipated at the time of deployment.

The last strong push in Ethereum was lead by Alexey Akhunov [4]. However,
despite sincere effort and multiple iterations, the project did not gain broad
community support. He directed attention to build a high performance ethereum
client – the Erigon project (previously called turbo-geth). Interestingly,
Erigon is focused on reducing the number of IO operations per SLOAD, which is
connected to this research on state access pricing.

Since the stalling of discussions related to storage rent, other alternatives
have been proposed. These include the concepts of state expiration or
hibernation, weak statelessness, and regenesis. Even if a blockchain takes
some steps to reduce current state size, a new client syncing with the chain
will still have to recreate all previous states for each transaction on the
main chain. For Ethereum this is not even worth trying with ordinary consumer
hardware and will get worse. Thus, it makes sense to move away from the
current approach of having new clients go through a sync from genesis.

However, if a new client starts syncing from a state of the system other than
genesis, they will need to get that state from somewhere, and this leads to
trust issues. Therefore, some of the new proposals also require new proofs of
validity i.e. witnesses. At present, even these efforts appear to have stalled
for over a year. This is partly because current attention is on “the merge“.
The other reason is that Ethereum clients in operation are already high end
machines, and those operating such nodes can deal with the additional RAM
requirements in the near to medium term. However, for other EVM chains, the
state may still be relatively small enough that introducing state rent can
help maintain relative growth of state size and system RAM in ordinary user
machines.

###  II-B Current Adoption Status

Thus far, Solana protocol appears to be the only blockchain that has deployed
a version of state rent on their main network [5]. Near protocol had
implemented a version of storage rent and it was deployed in their testnet.
However, they deprecated state rent before the launch of their mainnet. The
concerns that lead to the deprecation largely mirror those faced by the
Ethereum core developers. Near currently uses a model in which users stake
tokens to gain storage rights [6].

Solana protocol expects storage costs to fall rapidly. This has two design
consequences. The first is a two year horizon for their rent computations.
This is driven largely by expectations about explicit (physical) storage costs
being reduced by half each year. By contrast, our emphasis is on the implicit
cost of state size growth on the performance of nodes and decentralization.
These are _opportunity costs_ , not physical costs. For instance, state size
growth impacts ordinary users much more than block producers. Solana’s
emphasis is on block validators. Most end users are not really expected to run
Solana nodes. By contrast, we are concerned about users who want to run their
own EVM client nodes using consumer grade hardware on a home broadband
connection.

##  III Our Proposal

Rapid growth in state size is driven in large part by the lack of any pricing
for storage duration. Every action by a user which increases state size
imposes a negative externality on all other peers. Good engineering cannot
make up entirely for poor economics. Such conflicts between private benefits
and social costs are typically managed via taxes. Storage rent is just that -
an externality tax. Unlike the costs of reading or writing to state (SLOAD or
SSTORE), storage rent does not target the frequency of accessing state data.
Instead it targets (the product of) the size and the duration of storage.

Our main idea is very simple and generally applicable for all EVM chains. We
note that this work is linked to an improvement proposal for the RSK
blockchain [7] (also known as Rootstock). For completeness, we present a brief
note on RSK (following two paragraphs) which readers can skip without loss of
continuity.

RSK is an EVM compatible Bitcoin sidechain [8]. It uses proof of work for
consensus and is merged-mined with Bitcoin by some of the largest mining pools
(cumulatively representing over half of all hash power devoted to Bitcoin
mining). RSK does not have an independent native currency, it uses Bitcoin.
This is implemented via a federated 2 way peg between Bitcoin and the native
coin RBTC. The monetary supply of RBTC is determined by the amount of Bitcoin
locked to the (multisig) federation address via peg-in transactions on
Bitcoin. Like most federated pegs, the interesting bit is the peg-out from the
sidechain back to Bitcoin. The Federation members do not control the signing
keys, which are within hardware security modules (HSMs). These modules sign
peg-out transactions only when instructed by a bridge smart contract.

Bitcoin miners who merged-mine RSK only earn transaction fees. There cannot be
a block subsidy, since the network cannot create new RBTC without
corresponding deposits of Bitcoin. Implementing storage rent can increase
these fees, contributing to merged-mining rewards. This increase in block
producer fees from storage rent holds for proof of stake chains as well e.g,
Solana.

###  III-A Granularity of Rent

In this proposal, rent tracking and computation is at the level of the
individual pieces of state data. For most EVM chains this an individual,
value-containing (leaf) node, in the state trie. Ethereum has separate tries
for accounts and storage. However, for simplicity we refer to a single state
trie222The RSK blockchain actually has a single state trie that contains
account and contract data as well as storage cells. Moreover, unlike
Ethereum’s hexary trie, RSK uses a binary tree structure..

This granularity is different from earlier state rent proposals for Ethereum
where rent computation was at the level of an account, e.g. all of the storage
consumed by a contract. We adopt a much finer granularity. We track rent
payment status for each node in the trie by adding a timestamp for the last
time rent was collected for that node. This can be the timestamp of the block
in which the last rent update was made. The interpretation is that the node
owes rent since the timestamp.

#### Size

The obvious unit for size for rent computations is bytes used. However, when
computing rent for a trie node, we should account for the overhead of storing
information, including the key. For instance, even though a storage cell may
contain 32 bytes of data, the effective size is closer to 100 bytes as there
is an overhead of about 64 bytes. The same holds for a node containing account
information. Contract bytecode is obviously much larger and the overhead has
small impact.

#### Duration

The duration of state storage can be measured either in units of time (e.g.
unix seconds since last rent update) or a chain may use difference in block
height (since last update). We think seconds is more natural and is similar to
that in previous proposals.

#### Rental Rate

Rent is collected in gas, in addition to regular transaction fees. Given the
granularity, a rental rate $R$ will have units of gas per byte per second. In
our proposal for the RSK network [7] we use a value $R=1/2^{21}gas/byte/sec$.
This value corresponds to an annual rent of about 2500 gas for a storage cell
or an account. The rental rate is ad hoc and cannot be determined accurately
without an economic model of how a public EVM chain values state storage and
the costs of disk IO. This is unlike setting the gas cost schedule for various
EVM opcodes which can be linked to client performance benchmarks e.g.,
nanoseconds of CPU time under standardized test conditions.

Illustrative Example: Consider a transfer of some DAI (or any ERC20) tokens
from Alice to Bob. Some of the state trie nodes touched by this transaction
are: Alice’s account node (transaction sender), the trie nodes containing the
DAI smart contract bytecode, the storage cells containing application
parameters, the cells containing the mapping of addresses to token balances,
and finally the storage cells that contain Alice’s (token sender) and Bob’s
(token recipient) DAI balances. Most of these are trie reads with a few trie
writes.

###  III-B Attribution of Rent

Attribution asks “Who pays state storage rent and for what?” In our proposal,
we require the sender of a transaction to be partly responsible for paying a
portion of outstanding rent for each part of the state that their transaction
reads from or writes to. As will become clear, we expect a very small fraction
of transactions to trigger any rent payments. This is due to parameters for
rent caps and collection thresholds (explained below).

The account-based tracking and collection of rent of earlier rent proposals
has an implicit notion of ownership. We think that this notion of data
ownership is at odds with the idea of a public blockchain. We treat all state
data as collectively owned, and therefore the cost should be distributed
across users in a collective sense. However, collective ownership does not
mean equal allocation of dues. Instead, we distribute the burden of rent based
on who is consuming the data - i.e. a transaction sender.

For our illustrative example, in addition to the usual gas amount for
transferring some DAI to Bob, Alice (as transaction sender) may have to pay
some storage rent for the trie nodes touched by the transaction. If the amount
of rent due for any nodes is above the collection triggers, then all such rent
(subject to caps) will be deducted from the transaction’s gas limit.

###  III-C Rent Tracking and Computation

As a transaction is executed, we keep track of all trie reads and writes. At
the end of the execution, we check the rent timestamps for all the trie keys
accessed (reads and writes), and compute the amount of rent due. The total
amount of rent to be collected is consumed from the transaction’s gaslimit.
Unlike execution gas, which is consumed on the go, we think it is better to
collect rent at the end of transaction execution. Attempting to consume rent
on the go can lead to breaking changes. For example, any contract calls that
limit the amount of gas passed to the call can potentially break if we attempt
to consume rent (from the restricted budget) for the trie nodes accessed by
the internal transaction.

###  III-D Caps and Thresholds

Updating a rent timestamp involves a trie put operation, which is costly. So
we avoid collecting insignificant amounts in rent. Thus, for any trie node
touched by a transaction, we should collect rent only if it exceeds the cost
of updating rent timestamps. For example, we can set this minimum amount to
trigger a collection at 5000 gas, which is the cost of a write operation (e.g.
cost of a storage cell update). Of course, if a new value has to be written
anyway, e.g. updating an account or token balance, then the threshold for
collecting rent can be a smaller (e.g. 1000 gas). Thus, we have lower
thresholds for trie writes (e.g. SSTORE) and larger collection triggers for
pure trie reads (e.g. SLOAD).

If a part of the state is unused for a long time (e.g. an old library), it may
have a large amount of rent due. We should not place the burden of large rent
payments on the first user to access this unit of the state. Therefore, we
place limits on how much rent can be collected for a trie node in a single
transaction. For instance, we can set the cap at 10,000 gas per trie node (per
transaction).

If the amount of rent due for a trie node exceeds the cap, then the timestamp
cannot be advanced all the way as the current block timestamp. In such cases,
the timestamp is advanced in a manner consistent with the node’s size and the
amount of rent collected (i.e the cap).

Quasi-random rent collection: The existence of caps and thresholds implies
rent collection is state dependent. The same transaction sent at a different
time can lead to different rent computations. This is how rent payments are
‘randomly’ distributed across users. The probability distribution (size and
likelihood) of any user paying storage rent will depend on the type of user.
Those who engage more frequently with decentralized applications, and with a
wider variety of applications, are more likely to pay state rent than other
users with limited participation. The quasi-randomness in rent payments can
make gas estimation more challenging. However, we believe this is something
wallet developers can adapt to and optimize.

###  III-E Internal Nodes, State Expiration and Caching

Rent is only collected for value containing (typically, leaf) nodes in the
state trie. However, we propose that rent timestamps should also be included
in internal nodes as well. The timestamp for any internal node should be
updated to match that of the most recently updated child node. Doing so can
have several benefits. For instance, if an EVM chain decides to implement
state expiration, or hibernation, then they can use rent timestamps to
determine which parts of the trie to evict from state.

At present, we are not convinced about the soundness of proposals for state
expiration and recovery for EVM chains. Our view is that storing data on
drives is not that expensive (and is getting cheaper). Our attention should be
on the limitations of RAM and disk IO. In this regard, we think EVM chains can
use rent timestamps to create different levels of cache hierarchies without
ever deleting or evicting parts of the state. Instead, individual client
operators can decide how to organize their disk storage and use rent
timestamps to decide how far (from RAM) some parts of the state should be. For
instance, the parts of state with the oldest timestamps can be stored in the
slowest storage location. Portions of the state with recent timestamps can be
on RAM. Each client can set a local policy. This will incentivize users and
app developers to keep rent status fresh, so their transactions execute
faster.

We should point out that our suggestion to use timestamps for caching is in
contrast to a position adopted by Solana protocol. In that system, every part
of the state is checked for rent status at the end of each epoch. There is no
concept of dormancy or not paying rent during an epoch. This is starkly
different from our proposal where a part of the state may not be touched for
years. In our proposal, it is okay not to collect rent on a regular basis for
every part of the state. We think it is fine for such data to just stay on
disk without any consequence on RAM capacities or disk IO. This is also why we
think that it safe to stop accumulating rent for a trie node once it has not
been touched for some period of time, e.g. three years. There is no strong
economic reason to keep accumulating rent forever.

###  III-F Interaction with Refunds

At present, the only economic incentive for reducing state storage comes from
refunds for clearing storage cells and deleting (self-destructing) deployed
contracts. However, refunds have proved problematic in the past. There is not
much evidence that they encourage good state hygiene. On the contrary, refunds
have been blamed for speculative hoarding of storage e.g. gas tokens. This is
why Ethereum reduced the refunds for storage cells. Storage Rent does not
reduce state size by directly. That would be the case if rent is combined with
some kind of state expiration policy. However, we believe rent can work in
concert with gas refunds and provide additional incentive to reduce storage.

###  III-G Reverts, Deletions and DoS Attacks

Consider a transaction in which a contract loads hundreds of storage cells and
then self destructs. In this case, the contract and all its storage are
removed from state. Should we compute and collect storage rent in such cases?
While it may seem like collecting rent is not worth the effort, we have to
collect the rent due, up to the individual caps. Otherwise such patterns can
be used for DoS attacks.

Another pattern that can be used for DoS is for an attacker to attempt to load
parts of the state which they know not to exist. Even if these keys are not
part of the real state, such lookups force clients to search on disk. One way
to discourage such attacks is to raise the cost of trie reads. This is indeed
the path followed by several improvement proposals in Ethereum including
EIP-150,EIP-1884, and EIP-2929. Storage rent provides an additional way to
deal with such attacks without altering the pricing of EVM opcodes. If a key
that a user searched for does not exist, than we can collect a penalty as part
of the rent mechanism. This can be made something like the equivalent of one
year’s rent for a storage cell. Arguably, such penalties will impose costs on
legitimate use cases, and this can influence the choice of the penalty.

A proposal for storage rent must also consider what happens to the rent status
of parts of the trie that are accessed by a transaction which gets reverted
(including internal transactions). Since the transaction is reverted, no state
changes will be recorded. However, in such situations we must still collect a
fraction of the computed rent dues (e.g. 25 percent)] for these state changes
that are rolled back. The amount collected is in part compensation for rent
related computation, and also as deterrence against some DoS attacks.

##  IV Pricing of Rent

As noted in Buterin [2], one of the primary challenges in deploying storage
rent is how to determine the pricing. The gas cost schedule for various EVM
opcodes is (loosely) proportional to the resources consumed. These costs get
scaled by the gasPrice, which ultimately is determined by gas fee market.
Setting an appropriate level for storage rent will require experimentation and
tinkering.

For storage rent to have any impact on state size growth or IO operations, the
price must be economically significant. Measuring the impact requires price
experimentation. Estimating users’ and developers’ response to rent will be
hard and time consuming. Since rent is about economic incentives, deploying
storage rent on some testnets will not be very informative. Testnet is fine
for testing the engineering side of rent tracking, client performance, wallet
integrations, and user experience. But the economic impact will require long
term testing in a mainnet setting.

Suppose there is a proliferation of L2 chains that are essentially forks of
geth. If some of them implement storage rent while others do not, then that
could serve as a testing ground. However, even then, it would be hard to
control for the multiplicity of factors that affect user growth and adoption
across seemingly similar networks. Therefore, while plausible, we do not
expect such experiments as a promising path.

The only alternative is to have price experimentation within a single chain.
Introducing storage rent will require a network upgrade (a hard fork). It may
seem that performing any price experimentation may also hard forks to alter
the parameters for rent. However, it is impractical to think about
deliberately introducing hard forks in stable networks for price
experimentation. There are ways to get around this restriction. The first, is
to rely on natural variations in gasPrice and also coin prices. A more
intricate manner of performing price experiments (closer to randomized trials)
without hard forks is to include the experimental structures directly inside
the client. For example, we can include deterministic or randomly scheduled
rent-holidays. These could be periods during which rent collections can be
paused, or discounted in some manner. Such experiments can help recalibrate
the rental rate and measure user responses, which in turn can lead to more
effective pricing of state storage duration.

##  V Conclusion

Storage rent cannot solve all problems associated with state size growth.
However, it is one of very few tools that utilize a microeconomics approach
(of using externality pricing) to strike a balance between private benefits
and social costs. Our proposal is simple, yet highly stylized in some ways.
For example, rent payments cannot always be estimated or predicted with
precision. This will create some new headaches for wallet developers. However,
these problems are largely manageable and unlike previous proposals, there are
no breaking changes for preexisting contracts. It avoids the complications of
state expiration or regenesis, but can work alongside them.

At present, only Solana has implemented storage rent. Introducing rent in EVM
chains will require a hard fork. However, this is not a reason to avoid it.
Ethereum core developers have repeatedly demonstrated their ability of
introducing complex changes through open debate, community discussions, and
thorough testing. The complexity of implementing storage rent is relatively
mild in comparison to something like the recently activated ”merge” that
switched Ethereum’s consensus mechanism from proof of work to proof of stake.

Part of the challenge in introducing rent is cultural, not technical. If
Ethereum were to adopt rent, most other EVM chains will do so as well. If
Ethereum does not adopt it, then most EVM chains will remain hesitant.
However, it is entirely plausible that some chains experiencing rapid growth
may be compelled to act sooner than Ethereum. As noted in [1], some EVM chains
e.g. BSC, dialed back from operating at very high scale with block sizes
several times larger than Ethereum’s. Perhaps they were able to foresee the
problem of unmanaged state size growth. Perhaps some of these chains will join
RSK in exploring state rent as one part of a sustainable approach to
decentralized computation.

## References

  * [1] P. Szilágyi, “Ethereum in Numbers: Where Physics Meets TPS,” https://ethereum.karalabe.com/talks/2022-ethprague.html, 2022.
  * [2] V. Buterin, “Blockchain Rent,” https://github.com/ethereum/EIPs/issues/35, 2015.
  * [3] G. Wood, “Ethereum: A Secure Decentralised Generalised Transaction Ledger,” Ethereum, Tech. Rep., 2014.
  * [4] A. Akhunov, “State Fees (formerly State rent) pre-EIP proposal,” https://ethresear.ch/t/state-fees-formerly-state-rent-pre-eip-proposal-version-3/4996, 2019\.
  * [5] Solana Protocol, “Storage Rent Economics,” https://docs.solana.com/storage_rent_economics.
  * [6] Near Protocol, “Introduction to NEAR Protocol’s Economics,” https://near.org/blog/near-protocol-economics, 2020.
  * [7] S. Lerner, D. Masini, F. Jinich, and S. Mishra, “RSKIP240: Implementing Storage Rent in RSK,” https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP240.md, 2021.
  * [8] S. D. Lerner, “RSK White Paper Overview,” Rootstock, Tech. Rep., 2015.