Nie musisz. Skoro można składać sygnatury (patrz: sygnatury Schnorra), to można też składać transakcje (patrz: Pedersen Commitments). Co do tego drugiego, to nawet kiedyś to opisałem: viewtopic.php?f=45&t=35941.Jeśli o kilku, to musisz mieć A->B i B->C i obie na łańcuchu.
Wiem. Ale mogę kryptograficznie składać takie rzeczy, jak sygnatury i klucze publiczne. Co więcej: można napisać taki kod, aby sieć robiła to automatycznie. To się nazywa "skalowanie". Jeśli masz blok o rozmiarze N bajtów, który jest w stanie przetworzyć M transakcji, to oczywiście mając blok o rozmiarze 1000*N bajtów będziesz w stanie przetworzyć 1000*M transakcji. No ale to nie jest skalowanie, tylko liniowy wzrost. Skalowanie jest wtedy, kiedy występuje "efekt skali", czyli gdy jesteś w stanie za pomocą tych samych zasobów uzyskać lepszą przepustowość. I właśnie dlatego takie optymalizacje są potrzebne.Nie możesz sobie usuwać z bazy transferów pomiędzy podmiotami, bo takie masz widzimisię.
To jest problem prawny, a nie techniczny. Przecież dałoby się zrobić tak, żeby zamiast prawnego spaghetti mieć po prostu opłatę od transakcji, która byłaby całkowitym, ostatecznym, a także do bólu przejrzystym sposobem na płacenie podatków wszelkich. Co wolisz: płacić podatki poprzez opłaty transakcyjne i mieć święty spokój, czy przebijać się przez prawnicze spaghetti, które mamy dzisiaj, gdzie ludzie nawet nie wiedzą, ile i za co konkretnie mają zapłacić? Oczywiście, mamy to co mamy, ale myślę, że dążenie w kierunku prostszego systemu jest dobrym pomysłem.Policz mi przychody i koszty podatkowe podmiotu B, jeśli nie masz ewidencji w twoim przypadku.
Albo się coś kompresuje, albo nie. Jak nic nigdzie nie jest kompresowane, to ciężko mówić o tym, że występuje "efekt skali", bo bez żadnych optymalizacji, to jest tylko i wyłącznie "liniowy wzrost".Albo coś się fizycznie wydarzyło albo nie.