1/ Właśnie przełamaliśmy wąskie gardło związane z zobowiązaniem stanu w Eclipse: AlDBaran utrzymuje 48M aktualizacji/sek na 96-rdzeniowej maszynie AWS, przyspieszając rollup GigaCompute Eclipse.

2/ Dlaczego to ma znaczenie: 1M TPS -> 3M aktualizacji stanu/sek (~3 klucze/tx na Eclipse). Standardowe silniki ADS zacinają się poniżej 0,6 M/s, co stanowi 5-krotną różnicę, której nie zaakceptowaliśmy.

3/ Poznaj AlDBaran: dwa silniki zaprojektowane z myślą o stanie. 🔹 Pleiades - błyskawiczne aktualizacje w pamięci DRAM 🔹 Hyades - asynchroniczny, tylko do dopisywania magazyn dowodów

4/ Pięć zasad projektowania Pleiades: 1️⃣ Wykonanie tylko w DRAM (bez fsync/stron błędów) 2️⃣ Podział wątków (0 blokad) 3️⃣ Buforowanie gałęzi (opóźnienie haszowania górnego drzewa) 4️⃣ Grupowanie SIMD (16 haszy/operacja wektora) 5️⃣ Przewidywalny układ + prefetch (trafienia w pamięci podręcznej L2)

5/ Najważniejsze punkty benchmarku: - 48M ups na 96 rdzeniach dla Pleiades przy około 1B kluczy (0,5 M/rdzeń ≈ 78 % szczyt solo) i 40M ups nawet przy 8B kluczach - 24M ups z historią dla Hyades - Korzenie stanu teraz płynnie przechodzą przez łącze 50 Gbps.

6/ To 20× skok w porównaniu do 2,3M/s QMDB i 30× szybszy niż nasze wewnętrzne testy QMDB. Nasze wymaganie 3 M/s teraz zużywa < 7 % pojemności, co daje ogromny zapas.

7/ Hyades działa w pełni asynchronicznie, wprowadzając kompaktowe 40B dowody poza ścieżką do logu tylko do dodawania, podczas gdy pełne ładunki kont lądują w osobnym dzienniku. Gorąca ścieżka pozostaje nieskazitelna.

8/ Więcej informacji na temat architektury AlDBaran i głównych wyników można znaleźć na stronie: