大きな支払いができない（もしくは受取手の履歴検証負荷が上がる）という問題
ここがよくわからん
大きな支払いができないケース
→フラグメント化したセグメントを寄せ集めて支払うことを許さないならば
いくら細切れのセグメントを集めても支払いができない
→前提条件としてある『所有するsegmentが小さくなってしまうと』というのは具体的にどういう意味？誰が所有するsegment?; transaction の送り主
受取手の検証負荷(時間)があがる
→寄せ集めて支払うことを許すなら、セグメントひとつごとに所属するTokenIDがあり、その履歴をウォレットに蓄積している必要があるため、支払いに使用したセグメントの数だけ履歴の束が送信されてくる。履歴のサイズはセグメントのサイズに依存せず、Sum Merkle Treeの深さ と Deposit後に経過したブロック高 に依存する(=Segmentが小さいから履歴も小さいなんてことはない)ため、小さいセグメントは非効率であるとも言える。
t
When the assemblance of segements are allowed in the payment transaction processing procedure, there should be each TokenID corresponding to each segment, end users have to keep therir each transaction history of the segement in their wallet. That is to say, whenever transaction occurs, segments used in the transfer generates the bundle of history data, then it is sent to {where?}.