Da się czy się nie da?
1) da się
2) jest to strasznie nieoptymalne
Jest ta kompletność Turinga czy jej nie ma?
Wiesz, w ten sposób to można nawet bloki wykopywać i sam konsensus egzekwować, gorzej z wydajnością. No bo wtedy pojawia się pytanie: czemu akurat SHA-256? Przecież można zamiast mieć OP_SHA3, to sobie ręcznie robić pushe i składać wszystkie rundy. Można, ale jest to strasznie niewydajne.
Jedna transakcja BSV zajmująca 12 bloków BTC, czyż to nie piękne?
Raczej od 3 do 12 bloków, żeby być ścisłym, ale mniejsza z tym. Przede wszystkim kłopotliwe w utrzymaniu.
Opłata 33 centy przy obecnej cenie i stawkach dla górników. Wraz z większą ilością transakcji i większymi blokami, opłaty będą niższe.
Polemizowałbym, że zrobienie nowego opkodu OP_ZK_SNARK lub czegoś w tym stylu byłoby tańsze, prawdopodobnie analogiczna transakcja na takim łańcuchu, jak ZCash, byłaby tańsza i prostsza, bo łatwiej jest dołożyć nowy opkod w ten czy inny sposób, niż kombinować jak koń pod górkę. Żeby się o tym przekonać, wystarczy spojrzeć na Script. Czy jak czytasz "... OP_SWAP OP_CAT OP_SWAP OP_CAT OP_SWAP OP_CAT ...", to jest to proste i intuicyjne? A co, gdyby tam było OP_DUP zamiast OP_SWAP? Byłoby lepiej czy gorzej i dlaczego? No właśnie. Nie sądzę, że jesteś w stanie dokładnie wyjaśnić, jak działa ten Script i dlaczego tam jest OP_SWAP, a nie coś innego. Tym bardziej nie sądzę, że jesteś w stanie na pierwszy rzut oka stwierdzić, co tam się tak naprawdę dzieje i co należy zmienić, aby dołożyć do tego jakiś prosty warunek w środku.
Najpierw słyszeliśmy że sieć się wykrzaczy na 23BM blokach.
Ile węzłów opuściło sieć od tamtej zmiany?
Potem że 100MB blok jest nie do przejścia.
Jeśli celem jest zniechęcenie kolejnych węzłów, to owszem, można i tak.
Potem że nie ma kompletności Turinga.
Równie dobrze możesz powiedzieć, że każdy algorytm ma stałą złożoność obliczeniową, bo wykonuje się w skończonym czasie. Jestem ciekaw, ile będzie ważyła transakcja z wielokrotnie zagnieżdżonymi pętlami, gdy trzeba będzie każdą taką pętlę rozwinąć i całość zacznie wykładniczo przyrastać. Fibonacciego też można zrobić przez "0 1 OP_ADD 0 1 OP_ADD OP_ADD ...", tylko że to wtedy eksploduje. Same zera, jedynki, a także OP_ADD wystarczą, nie potrzeba żadnych innych opkodów. A jednak lepiej jest mieć takie OP_2DUP, żeby sobie ułatwić życie, prawda?
Teraz że transakcja zk-SNARK zajmuje za dużo miejsca
Bo tak jest. Jeśli to żaden problem, to przecież teraz można cały łańcuch ZCash wciągnąć, prawda? Co, u nas się nie zmieści? Dawaj, kopiemy!
Co będzie następne?
Zależy, jaki ficzer chce mieć BSV. Może Monero i RingCT? Tam zajmuje to około 1800 bajtów, ciekawe, ile zajmie tutaj i czy cały łańcuch Monero też można sobie zassać na BSV. Jak szaleć, to szaleć!
BSV buduje, BSV pokazuje że DA SIĘ!
Pewnie, że się da. Każdy problem można tak rozwiązać. Kopanie jest zbyt scentralizowane? Olać to, niech każdy górnik zgłasza każdy share i wpycha to na łańcuch. Jeśli jeden blok zajmuje 4 GB, to jeśli mamy 1000 bloków o niższej trudności w jakimś poolu w ciągu 10 minut, to dawaj, ładujemy 4 TB na łańcuch, a co! Da się? Pewnie, że się da. Milion shares? Spoko, 4 PB na 10 minut. Można? Można. Warto? Oczywiście nie, ale jeśli BSV tak zrobi, to mnie nie zdziwi.
Wolicie kupować shitcoiny i zastanawiać się czy 600% APY na jakimś scamie to dobry interes.
Nie patrzę na spekulację.
Tutaj macie technologię, która działa i wciąż wam coś nie pasuje, bo trudno jest przyznać się wam do pomyłki.
Jakiej pomyłki? Przecież dawno temu napisałem, że jeśli Script byłby Turing-complete tak, jak ja to rozumiem, to ważyłby więcej niż normalnie, przez co wprowadzenie nowego opkodu jest wydajnościowo lepsze w takim przypadku (bodajże nawet pisałem wprost o "gigabajtowych scriptach"). Tym bardziej, że jeśli jakaś transakcja waży powiedzmy jakieś 1200 bajtów, to widać wyraźnie, na czym polega różnica: jedna transakcja zk-SNARK, czy tysiąc zwykłych transakcji o zwykłym rozmiarze? Wiesz, ile rzeczy można zrobić, wykonując tysiąc normalnych transakcji?
Edit:
Ludzie nauki akceptują nowe fakty i odrzucają nieprawdę. Polecam.
Znalazłem swój stary wpis. Jeśli źle pisałem, to podaj, w którym miejscu się myliłem.
garlonicon pisze: ↑ niedziela, 16 lutego 2020, 11:06
Co do tego, że Script może być Turing-complete, to nie mam wątpliwości. Widzę jednak pewien problem: koszt praktycznego stosowania czegoś takiego. Otóż Script nie ma żadnych pętli. Co z tego wynika? Ano to, że aby taką kompletność Turinga uzyskać, to trzeba powtórzyć dany ciąg opkodów tyle razy, ile razy maksymalnie mógłby się wykonać warunek wewnątrz ifa (czyniąc z niego sztucznie rozwiniętą pętlę tak, jak to niekiedy robią kompilatory). I teraz tak: z jednej strony spoko, bo się da. Z drugiej strony: czy ma sens pchanie do blockchaina gigabajtowej wielkości skryptu po to, aby na przykład umożliwić wydanie monet na podstawie własnej funkcji skrótu?
Edit: CTRL+F, "47fd7cd8168c203c8dca7168916a81975d588181b64550b829a031e1724e6430": 198 wystąpień. Łohoho, to nie tylko jest długie i waży prawie 12 MB. To zawiera powtórzone 256-bitowe liczby, co można byłoby skrócić, stosując inne opkody, na przykład OP_DUP. Wniosek? Nie tylko to jest kosztowne, ale również strasznie źle zoptymalizowane. Poza tym, widać, że autor użył OP_TOALTSTACK, więc ma świadomość istnienia więcej niż jednego stosu i powinien umieć zrobić takie rzeczy. No i z tego też wynika kolejna kwestia: jak masz OP_ZK_SNARK, to wiesz, jak ludzie tego używają i każdy programista wie, co z tym zrobić. A jak masz taki długi Script, to "każdy sobie rzepkę skrobie", co skutecznie zniechęca na przykład do tego, aby stawiać własny węzeł, skoro topornie się to kompresuje (bo każdy sobie to zoptymalizuje inaczej, więc nie można hurtowo skompresować wszystkich tego typu transakcji w ten sam sposób).