Paolo Ardoino chce, aby AI zarządzało kopalniami Bitcoin. Kto otrzymuje pozwolenie na działanie?

Pojawienie się AI w kopalniach Bitcoin, które promuje Paolo Ardoino, opiera się na decyzji ludzkiej: kto może upoważnić maszynę do zmiany tego, co robi? Narzędzie do działania urządzeń w odniesieniu do MDK v0.11 Tethera wstrzymuje swoje działanie do czasu uzyskania zgody człowieka, podczas gdy strona musi ustalić, kto ma prawo to zrobić.

Ta różnica ma znaczenie, ponieważ Tether ogłosił zobowiązania od 15 uczestników branży 24 października do budowy i utrzymania integracji z jego Zestawem Rozwoju Kopalni, otwartym frameworkiem łączącym sprzęt górniczy, pule i aplikacje. Wspólny interfejs może zapewnić oprogramowaniu spójny sposób dotarcia do różnych systemów. Pozwolenie na działanie nadal zależy od instalacji.

Przykład v0.11 nie ustala, jaki kod zainstalowały QVAC lub uczestniczące kopalnie. Nowszy kod głównej gałęzi dodaje ograniczenia dla wywołujących, których brakuje w tej etykiecie. Kontrola strony zależy więc zarówno od tego, kto może wydawać polecenia, jak i od tego, jakie oprogramowanie górnicze przyjmuje kopalnia.

Od integracji do poleceń sprzętowych

Lista Tethera obejmuje BITMAIN, MicroBT, Canaan, Bitdeer, Foundry Digital i Luxor Technology. Wymienia również ACME Swisstech, Elektron Energy, EMCD, F2Pool, Heatbit, OCEAN, Proto, SpiderPool i Stratum V2.

Zgodnie z ogłoszonym porozumieniem uczestnicy będą budować i utrzymywać Pracowników: oprogramowanie, które przekształca istniejący sprzęt firmy, pulę lub interfejs systemu w wspólny język MDK. Każda firma wybiera funkcje, które udostępnia. Aplikacja może następnie korzystać z tego interfejsu, zamiast wymagać osobnej integracji dla każdego producenta.

Tether twierdzi, że jego agent górniczy QVAC już działa na MDK jako wczesna demonstracja. Ogłoszenie nie podaje pojemności floty uczestniczącej, udziału w hashrate Bitcoin ani zmierzonych oszczędności.

Narzędzie akcji na stronie referencyjnej v0.11 akceptuje jedno nazwane urządzenie i oferuje dwie operacje: zrestartowanie go lub zmianę trybu zasilania. Opcje trybu zasilania to niski, normalny, wysoki i uśpiony, a obsługujący sprawdza, które tryby to urządzenie obsługuje przed wysłaniem polecenia.

To są możliwości przykładu, a nie górna granica dla każdej aplikacji lub Pracownika, którego ktoś mógłby zbudować z MDK.

Narzędzie referencyjne jest wyraźnie oznaczone jako zapis. Gdy pętla wykonawcza agenta napotyka narzędzie klasyfikowane jako wymagające zatwierdzenia, emituje zdarzenie oczekiwania na zatwierdzenie i wstrzymuje się przed jego wywołaniem. Odrzucenie uniemożliwia wywołanie. Wtyczka agenta Gateway dokumentuje domyślny dwuminutowy czas zatwierdzenia, a nieodpowiedziane zapytanie kończy się odrzuceniem.

Wtyczka v0.11 wiąże sesje i zatwierdzenia z tożsamością, która je stworzyła. Gdy nie dostarczono tożsamości użytkownika, zapytania korzystają z wspólnego lokalnego operatora. W tej konfiguracji wstrzymanie zatwierdzenia nie rozróżnia jednego człowieka od drugiego.

Kopalnia, która montuje tę wersję, musi zatem połączyć swoje własne kontrole tożsamości z powierzchnią zatwierdzenia. Osoba, która ma prawo do przeglądania danych sprzętowych, oraz osoba, która ma prawo do zatwierdzenia zmiany trybu zasilania, potrzebują uprawnień ustalonych przez stronę.

Ta sama decyzja wdrożeniowa dotyczy danych. Referencja agenta wspiera lokalne modele QVAC i hostowane punkty końcowe; z dostawcą hostowanym, podpowiedzi i wyniki narzędzi opuszczają stronę na hosta tego punktu końcowego. Uruchomienie agenta lokalnie i wybór miejsca, w którym działa jego model, to oddzielne decyzje konfiguracyjne.

Ścieżka poleceń zmienia kontrolę uprawnień

Oznaczony blueprint bezpieczeństwa v0.11 rozróżnia bezpośrednie polecenia od działań wymagających zatwierdzenia. Bezpośrednie wywołania command.request nie mają kontroli uprawnień po stronie jądra. Oddzielna trasa action.push korzysta z uprawnień dostarczonych przez przyjętego wywołującego backendu, więc Gateway, punkt wejścia aplikacji, musi je wyprowadzić od zweryfikowanego użytkownika.

Tutaj Kernel koordynuje żądania między aplikacjami a Pracownikami. Klucz pozwalający procesowi zaplecza na kontakt z nim ustala przyjęcie tego procesu. Nie identyfikuje on człowieka proszącego o zmianę.

Implementacja Pracownika v0.11 dodaje kolejny aspekt do rozważenia: jego interfejs poleceń sieciowych przekazuje żądania bez sprawdzania klucza wywołującego. Oznaczony plan ostrzega, że partner, który może dotrzeć do Pracownika i skierować do niego swój klucz publiczny, może bezpośrednio przesyłać polecenia. Ta ekspozycja zależy od sieci i instalacji; nie ustala, że konkretna kopalnia eksponuje swoich Pracowników.

W związku z tym, zatwierdzenie w czacie referencyjnym obejmuje tę interakcję agenta. Ograniczenie każdej trasy do sprzętu wymaga również kontroli wokół innych punktów dostępu.

Nowszy kod repozytorium zmienia ten obraz. Odniesienia GitHub sprawdzone 24 października mapują v0.11.0 do commit fae8fbce052a i główny do 35c144f240f0. W ostatnim przypiętym zrzucie, Pracownicy wymagają kluczy wywołujących, chyba że włączone jest ustawienie allowAll.

Jego dziennik zmian oznaczony jako v0.12 również opisuje role Kernela do odczytu, zapisu i administracji, opcjonalne narzędzia do zapisu MCP oraz zadeklarowaną weryfikację stanu urządzenia.

Tymczasem opublikowany przewodnik bezpieczeństwa, pobrany 24 października, wciąż opisuje Pracowników bez listy dozwolonych wywołań. Operator musi dopasować przewodnik do wdrożonego kodu, zanim uzna którykolwiek z nich za opis ochrony witryny.

Władza wydania pozostaje w projekcie

Wybór oprogramowania przez kopalnię łączy ją również z zarządzaniem wydaniami MDK. Dokument zarządzający projektem nadaje zespołowi rdzeniowemu ostateczną władzę nad projektem, Głównemu Utrzymującemu ostateczną władzę techniczną nad scaleniami, architekturą i planowaniem wydania, a Menedżerowi Społeczności ostateczną władzę nad kierunkiem strategicznym i mapą drogową.

Zobowiązanie do integracji samo w sobie nie przyznaje uczestnikowi władzy nad wydaniami MDK. Również władza do scalania kodu upstream nie ustala pozwolenia na wydawanie poleceń wewnątrz kopalni.

To sprawia, że przeglądanie aktualizacji jest odpowiedzialnością operacyjną. Polityka bezpieczeństwa v0.11 mówi, że poprawki są obsługiwane na zasadzie najlepszego wysiłku dla najnowszego głównego commita i że starsze commity lub oznaczone wydania mogą ich nie otrzymać. Wybór wersji ustala podstawę kodu witryny, podczas gdy konfiguracja określa, jak ten kod jest używany. Kolejne zmiany wymagają własnego przeglądu.

Nowszy dziennik zmian rozróżnia między akceptacją poleceń a potwierdzeniem wynikowego stanu urządzenia, ilustrując, co jest na szali. Pozwolenie na wysłanie instrukcji dotyczącej trybu zasilania i dowód, że maszyna osiągnęła żądany tryb, odpowiadają na różne pytania operacyjne.

Autonomia kopalni zależy od tego, kto może zatwierdzić zapisy, które programy zaplecza mogą dotrzeć do sprzętu oraz kto przyjmuje aktualizacje oprogramowania.