sieć octra

Jedyny L1 zbudowany
od zera dla FHE.

Inne projekty nakładają FHE na istniejący blockchain jak plaster.
Octra zaprojektowała każdą warstwę stosu wokół zaszyfrowanych obliczeń — od konsensusu po AML.

17k+TPS — testnet peak
<1sczas finalizacji bloku
6natywnych operacji HFHE
1Bmax supply OCT
octra vs. reszta

Dlaczego HFHE bije TFHE na głowę
jeśli chodzi o blockchain?

zama.ai fhEVM to pioniерski projekt — ale zaprojektowany dla Ethereum, gdzie każda operacja FHE to oddzielna transakcja. Octra zrobiła to inaczej.

parametr
zama.ai fhEVM
TFHE na EVM
inEVM FHE
ogólne podejście
Octra HFHE
natywny L1
architektura
FHE nałożone na EVM
precompile / plugin
natywny L1 od zera
przepustowość
~10–50 TPS (FHE ops)
~100–500 TPS
17 000+ TPS
czas operacji FHE
sekundy–minuty / op
sekundy / op
milisekundy / op
koszt FHE operacji
wysoki (gas × obliczenia)
wysoki
niski (natywna opłata)
równoległość
sekwencyjne bramki
ograniczona
masowa (hipergraf)
język kontraktów
Solidity + typy fhe*
zależnie od VM
AML — natywne ct_int
prywatne saldo
nie natywne
nie natywne
natywnie w protokole
stealth transactions
brak
brak
wbudowane
sealed compute env.
brak
brak
Circles
wyrok
za wolne dla produkcji na scale
kompromis architektoniczny
zaprojektowane dla FHE od zera ✓
// dlaczego to ma znaczenie:
TFHE wykonuje każdą bramkę logiczną sekwencyjnie — to jak liczyć na kalkulatorze jeden przycisk na raz.
HFHE przetwarza całe zestawy bramek równolegle przez strukturę hipergrafu — jak procesor z wieloma rdzeniami.
Na praktycznym przykładzie: porównanie 1000 zaszyfrowanych ofert aukcji zajmuje w TFHE minuty. W HFHE — sekundy.
architektura

Cztery warstwy. Zero kompromisów.

Każda warstwa zaprojektowana wokół FHE — nie dobudowana do istniejącego stosu.

L4

Circles — sealed compute environments

Izolowane aplikacje z zaszyfrowanym stanem. Hostowanie bez serwera, DNS ani CDN — bezpośrednio na sieci. Adres: oct://circle_id/path. Sealed: stan widoczny tylko dla uczestników. Public: wynik jawny, wejście prywatne.

L3

OVM — Octra Virtual Machine

VM wykonująca kontrakty AML (AppliedML) skompilowane do bytecode. Natywne typy zaszyfrowane: ct_int, ct_bool. Każdy kontrakt w izolowanym sandboxie. Bez EVM-kompatybilności — bez legacy ograniczeń.

L2

HFHE Engine — libpvac (C++)

Silnik obliczeń homomorficznych oparty na hipergrafach. Masowa równoległość zamiast sekwencyjnych bramek TFHE. Natywne operacje na zaszyfrowanych danych:

ct_add ct_sub ct_gte ct_and ct_or ct_not ct_mul — planned
L1

Consensus — OCaml / async DAG

Warstwa konsensusu napisana w OCaml. Asynchroniczny DAG umożliwia przetwarzanie wielu bloków równolegle — kluczowe dla throughput przy kosztownych obliczeniach HFHE. Testnet peak: 17 000 TPS.

hfhe — jak to działa

Hipergraf zamiast kraty.

Klasyczne FHE (BGV, TFHE) operuje na kratach algebraicznych — strukturach matematycznych które wymuszają sekwencyjność. HFHE robi to inaczej.

Hiperkrawędź = wiele bramek jednocześnie

W TFHE jedna bramka logiczna = jedna operacja w czasie. W HFHE hiperkrawędź może łączyć dziesiątki węzłów naraz — wszystkie obliczane równolegle w jednym kroku obliczeniowym.

Natywne saldo zaszyfrowane

Saldo każdego konta jest zaszyfrowane na poziomie protokołu — nie kontraktu. Żaden węzeł sieci nie zna wartości salda. Prywatność domyślna, nie opcjonalna.

Stealth transactions w protokole

Każda transakcja może mieć ukryty adres odbiorcy generowany jednorazowo. Obserwator sieci nie powiąże transakcji z adresem docelowym — nawet znając adres nadawcy.

Sealed auctions, private voting, dark pools

Aplikacje wymagające porównywania zaszyfrowanych wartości bez ich ujawniania. ct_gte porównuje dwie zaszyfrowane liczby i zwraca zaszyfrowany bool — wynik bez odkrywania wejść.

AML — język zbudowany dla prywatności

Nie Solidity z nakładką FHE. Własny język z natywnym ct_int i ct_bool — kompilator nie pozwoli przypadkowo ujawnić zaszyfrowanych danych.

sealed_auction.aml
// Sealed bid auction — nikt nie widzi cudzych ofert // winner wyłaniany przez HFHE bez ujawniania liczb contract SealedAuction { state { owner: address highest: ct_int // zaszyfrowana winner: address active: int } fn bid(amount: ct_int): bool { require(self.active == 1) require(value >= MIN_DEPOSIT) // ct_gte: porównanie na szyfrogramach // serwer nie widzi żadnej wartości let is_higher = ct_gte(amount, self.highest) if is_higher { self.highest = amount self.winner = caller } return is_higher } view fn get_winner(): address { require(self.active == 0) return self.winner } } // deploy: ~200 000 OU = 0.2 OCT // ct_gte: milisekundy zamiast sekund (TFHE)
circles

Circles — aplikacje bez serwera.
Dane bez dostępu.

Wyobraź sobie Vercel, gdzie nikt — włącznie z dostawcą — nie widzi danych użytkowników. To jest Circles.

sealed

Sealed Circle — pełna prywatność

Stan aplikacji jest zaszyfrowany. Tylko uczestnicy z kluczem dostępu widzą dane. Sieć wykonuje obliczenia — ale widzi tylko szyfrogramy. Idealne dla: private voting, sealed auctions, confidential data rooms.

public

Public Circle — prywatne wejście, jawne wyjście

Dane wejściowe prywatne, wynik publiczny i weryfikowalny. Nikt nie wie co wnosisz — każdy widzi co z tego wychodzi. Idealne dla: public AMM z private positions, rankingi bez ujawniania danych.

hosting

Bez serwera, bez DNS, bez CDN

Pliki statyczne przechowywane w sieci. Adresowane przez oct://circle_id/path. Aplikacja istnieje dopóki istnieje sieć — nie dopóki płacisz za hosting. Nie można jej "wyłączyć".

izolacja

Izolowane środowisko obliczeniowe

Każdy Circle ma własny zaszyfrowany stan, własne klucze, własne zasoby. Circles nie komunikują się bezpośrednio bez zgody uczestników. Naturalna granica bezpieczeństwa między aplikacjami.

zastosowania — realne

Co możesz zbudować już dziś.

Tylko to, co można faktycznie zbudować na obecnym mainnecie. Bez "może kiedyś".

🔨

Sealed auction / dark pool

Aukcja gdzie nikt nie widzi cudzych ofert do momentu zamknięcia. ct_gte porównuje zaszyfrowane bidy — winner wyłaniany bez ujawniania kwot. Zero front-runningu z definicji.

już istniejeOctraEx — działający sealed auction na mainnecie. octraex.org ↗
🗳️

Private voting / DAO governance

Głosowanie gdzie wynik jest publiczny, ale kto jak głosował — nie. Eliminuje presję społeczną i korupcję głosów. Matematyczna gwarancja tajności przy pełnej weryfikowalności wyniku.

buduj z:ct_add na zaszyfrowanych głosach, reveal tylko sumy końcowej
💳

Prywatne przelewy i saldo

Saldo zaszyfrowane natywnie w protokole. Transakcje z ukrytymi adresami odbiorców (stealth). Nikt w sieci nie widzi ile masz ani komu wysyłasz — bez Layer 2, bez mixera.

już działaNatywna funkcja mainnet — dostępna w wallet.octra.org i portfelach 0xio
🏥

Prywatne dane medyczne on-chain

Szpital przechowuje dane pacjentów w sealed Circle. Model diagnostyczny oblicza wynik na zaszyfrowanych danych. Ani szpital, ani sieć nie widzi wyników innych pacjentów.

wymaga:ct_add, ct_gte + sealed Circle + klucze dostępu per-patient
📊

Compliance bez ujawniania danych

Firma udowadnia regulatorowi że spełnia wymogi AML/KYC bez ujawniania danych klientów. Wynik: "compliant / non-compliant" — bez dostępu do bazy. Zgodność z RODO z definicji.

wzorzec:zaszyfrowany wektor transakcji + publiczny wynik weryfikacji

Cross-chain FHE bridge

Zewnętrzna sieć (Ethereum, Solana) deleguje zaszyfrowane obliczenia do Octra i odbiera wynik — bez ujawniania danych wejściowych. Octra jako warstwa confidential compute dla całego Web3.

w budowie:Octra FHE Bridge — wOCT jako token ekonomiczny protokołu
tokenomika

OCT — paliwo zaszyfrowanej sieci.

Każda prywatna operacja kosztuje OCT. Im więcej FHE compute — tym więcej popytu na token. Źródło: docs.octra.org

1B max supply

630M przy Genesis. 580M w obiegu od startu. Emisja kontrolowana przez protokół bez centralnej kontroli.

$20M publiczna sprzedaż

10% supply. Bezpośrednio z protokołu — bez VC lockupów wpływających na cenę w pierwszych miesiącach.

1M OU = 1 OCT

OU (Octra Units) — bazowa jednostka jak wei w Ethereum. Eliminuje błędy zaokrągleń przy obliczeniach opłat.

0.2 OCT — deploy kontraktu

200 000 OU. Prywatny transfer ≈ 0.005 OCT. Każda operacja HFHE płatna natywnie w OCT — bez gas auctions.

wOCT live na Uniswap v3

Wrapped OCT (ERC-20) handlowany na Ethereum. Bridge: bridge.octra.org. Contract: 0xb307...f0F

OCT do czego służy

Opłaty za transakcje, HFHE compute, deploy kontraktów, Circles, stealth transfers, nagrody dla walidatorów.

zacznij

gotowy żeby budować?

// portfel · OCT · AML · deploy · community