Problem z sidechainami jest taki, że na przykład BIP-300 albo BIP-301, to są soft-forki. Oznacza to tyle, że społeczność BTC musiałaby się zgodzić na wprowadzenie takich rzeczy, można je odrzucić, po prostu i zwyczajnie nie aktualizując softu i nie instalując nowszej wersji. Jeśli większość mocy obliczeniowej byłaby przeciwko, to ciężko byłoby przepchnąć coś takiego. Powstałby kolejny, niepotrzebny podział, gdyby ktoś się uparł na wprowadzenie takich zmian, bez uzyskania konsensusu.
To nas prowadzi do interesującego pytania: jeśli sidechainy są dobre, to dlaczego Bitcoin nie jest sam w sobie sidechainem? Otóż okazuje się, że idąc tym tokiem rozumowania, dochodzimy do koncepcji, którą ja nazywam "warstwą zerową". Wynika to z tego, że Bitcoin jako łańcuch jest uznawany za warstwę pierwszą, podobnie zresztą postępuje sporo altcoinów, które nie mają nad sobą żadnego innego łańcucha i nie są wpięte nigdzie indziej. W takim kontekście sidechainy zwykle stanowią warstwę drugą, natomiast Lightning Network to taka "warstwa półtora", bo nie jest wystarczająco samodzielna, aby mogła stanowić warstwę drugą w ścisłym znaczeniu tego słowa (na przykład, nie można przesłać monet komuś bezpośrednio, jeśli nie poinformujemy o tym fakcie warstwy głównej, tworząc odpowiedni kanał).
Zwykle ludzie myślą o sidechainach w kontekście warstwy drugiej lub niższej, to znaczy: myślą o zmianie warstwy pierwszej, żeby umożliwić wprowadzenie warstwy drugiej. Koncepcja warstwy zerowej zakłada odwrotne podejście: należy napisać taki kod, który umożliwiłby wciągnięcie istniejącego łańcucha jako sidechain do tego, co powstanie. W ten sposób, warstwa niższa nie jest w stanie tego w żaden sposób zablokować. Żeby to zatrzymać, należałoby zepsuć wiele innych rzeczy, na przykład uniemożliwić ludziom przesyłanie monet tam, gdzie chcą, ewentualnie zabronić podpisywania im takich wiadomości, jakich chcą. Dlatego ten pomysł jest ekstremalnie trudny do ocenzurowania.
Z technicznego punktu widzenia, taki łańcuch zawierałby ciąg nagłówków bloków, które pasowałyby do podanego algorytmu, na przykład SHA-256d. Co więcej, nawet Script zawiera opkod OP_HASH256, więc dałoby się to egzekwować na poziomie Scriptu, jeśli byłaby taka potrzeba. Ponieważ jednak warstwa niższa może być dowolnie prosta, nawet łańcuch oparty tylko na P2PK dałoby się wciągnąć pod spód.
Na warstwie zerowej, transakcje zawierałyby nagłówki bloków. Najprostszy możliwy model może zakładać, że po prostu śledzimy same nagłówki i że każdy może zajrzeć do środka, używając czegoś w rodzaju dowodów SPV:
hash bloku -> nagłówek bloku -> merkle root -> merkle proof -> ... -> merkle proof -> hash transakcji -> dane transakcji -> wyjście transakcji (32 bajty) (80 bajtów) (32 bajty) (64 bajty) (64 bajty) (32 bajty) (N bajtów) (N bajtów)
W ten sposób, warstwa górna może się opierać na dowolnym modelu. Może ustalić swoją podaż tak, aby wszystkie kwoty były w przedziale [0;100] i stanowiły "procent posiadanych monet". Może aktywować dowolne zmiany z dowolnych łańcuchów. Wszystko zależy od twórcy warstwy górnej, natomiast warstwa dolna jest jedynie śledzona. Docelowo, jeśli warstwa górna stałaby się lepsza, ludzie mogliby się całkowicie tam przerzucić. Nawet nie trzeba palić monet, wystarczy je podpisać we właściwy sposób, aby w razie potrzeby był możliwy powrót do warstwy dolnej, gdyby jednak warstwa górna zawiodła.
Co więcej, na warstwie zerowej cała zabawa się nie kończy: można iść do warstwy minus pierwszej, minus drugiej, i tak dalej, kompresując dane coraz bardziej i zostawiając problem ich przechowywania warstwom niższym oraz jej użytkownikom.
