Zeige mir das potentiell einfachste Gerüst eine zeitkettenbasierte Losdemokratie auf einer ARC GPU und Open Source zu ermöglichen.
15sek
Kurz, pragmatisch, startfähig. Fokus: kleinstes lauffähiges Gerüst („MVP“) für eine zeitkettenbasierte Losdemokratie mit Intel ARC via SYCL/oneAPI. Ziel: offene, reproduzierbare Auswahl per Hash-Los aus einem Seed je Block.
- Minimalprinzip
Identitäten: feste, vorab registrierte Participant{id, pubkey} (Sybil-Frage vorerst ignoriert).
Seed je Block: seed_{n} = H(block_{n-1}.hash || aggregate_sig || round_number).
Losziehung: Jeder Teilnehmer prüft lokal: H(seed || id || epoch) < target ⇒ ist gezogener Jurorin.
Block: enthält prev_hash, height, seed, chosen_set, proposals, signatures.
Konsens (vereinfacht): Eine Leaderin = „kleinstes Hash“-Gewinner; Quorum-Signatur bestätigt Block. Keine Fork-Auflösung außer „längste-Kette“.
zeitlot/
CMakeLists.txt
include/
hash.hpp
types.hpp
vdf.hpp (optional stub)
src/
main.cpp
chain.cpp
lottery.cpp
net_stub.cpp
gpu/
sha256_sycl.hpp
data/
genesis.json
README.md
- Kernlogik (Losziehung auf ARC via SYCL)
Host-Seite (C17, DPC) – Batch-Hashing
// src/lottery.cpp
#include <sycl/sycl.hpp>
#include
#include
#include "sha256_sycl.hpp"
struct Participant { std::array<uint8_t,32> id; /* pubkey etc. */ };
std::vector lottery_select(
const std::array<uint8_t,32>& seed,
const std::vector& P,
uint64_t epoch,
const std::array<uint8_t,32>& target)
{
using U8 = uint8_t;
const size_t N = P.size();
std::vector inputs(N * (32+32+8)); // seed||id||epoch
for (size_t i=0;i<N;i) {
auto* dst = &inputs[i*(72)]; // 32+32+8
memcpy(dst, seed.data(), 32);
memcpy(dst+32, P[i].id.data(), 32);
for(int b=0;b<8;b) dst[64+b] = (epoch >> (56-8*b)) & 0xFF;
}
std::vector<std::array<U8,32>> hashes(N);
sycl::queue q{ sycl::gpu_selector_v }; // ARC über Level Zero
sha256_batch(q, inputs.data(), 72, hashes.data(), N); // siehe Kernel unten
std::vector<Participant> winners;
for (size_t i=0;i<N;i++) {
if (memcmp(hashes[i].data(), target.data(), 32) < 0) winners.push_back(P[i]);
}
return winners;
}
SYCL-Kernel (vereinfachtes SHA-256, one-item-per-work-item)
// gpu/sha256_sycl.hpp
#pragma once
#include <sycl/sycl.hpp>
#include
using U32 = uint32_t; using U8 = uint8_t;
namespace sha256 {
static inline U32 rotr(U32 x, U32 n){ return (x>>n)|(x<<(32-n)); }
static inline U32 ch(U32 x,U32 y,U32 z){ return (x&y) ^ (~x&z); }
static inline U32 maj(U32 x,U32 y,U32 z){ return (x&y) ^ (x&z) ^ (y&z); }
}
static const uint32_t K[64] = { /... standard SHA-256 K .../ };
inline void sha256_batch(sycl::queue& q,
const U8* in, size_t in_len,
std::array<U8,32>* out, size_t N)
{
// Annahme: in_len == 72 Bytes (seed||id||epoch), Single-Block mit Padding im Kernel
sycl::buffer<const U8,1> bin(in, sycl::range<1>(Nin_len));
sycl::buffer<U8,1> bout(reinterpret_cast<U8>(out), sycl::range<1>(N*32));
q.submit([&](sycl::handler& h){
auto I = bin.get_access<sycl::access::mode::read>(h);
auto O = bout.get_access<sycl::access::mode::write>(h);
h.parallel_for(sycl::range<1>(N), [=](sycl::item<1> it){
size_t i = it.get_id(0);
// Message block (72B + padding → 2 Blocks à 64B)
U8 M[128];
// copy 72 bytes
for (int j=0;j<72;j++) M[j] = I[i*in_len + j];
// padding
M[72] = 0x80;
for (int j=73;j<120;j++) M[j] = 0;
// length in bits = 72*8 = 576 bits
uint64_t bitlen = 576;
for(int b=0;b<8;b++) M[120+b] = (U8)((bitlen >> (56-8*b)) & 0xFF);
auto process_block = [&](const U8* blk, U32& a,U32& b,U32& c,U32& d,U32& e,U32& f,U32& g,U32& h0){
U32 w[64];
for(int t=0;t<16;t++){
int k=t*4;
w[t] = (U32(blk[k])<<24)|(U32(blk[k+1])<<16)|(U32(blk[k+2])<<8)|U32(blk[k+3]);
}
for(int t=16;t<64;t++){
U32 s0 = sha256::rotr(w[t-15],7) ^ sha256::rotr(w[t-15],18) ^ (w[t-15]>>3);
U32 s1 = sha256::rotr(w[t-2],17) ^ sha256::rotr(w[t-2],19) ^ (w[t-2]>>10);
w[t] = w[t-16] + s0 + w[t-7] + s1;
}
for(int t=0;t<64;t++){
U32 S1 = sha256::rotr(e,6)^sha256::rotr(e,11)^sha256::rotr(e,25);
U32 ch = sha256::ch(e,f,g);
U32 temp1 = h0 + S1 + ch + K[t] + w[t];
U32 S0 = sha256::rotr(a,2)^sha256::rotr(a,13)^sha256::rotr(a,22);
U32 maj = sha256::maj(a,b,c);
U32 temp2 = S0 + maj;
h0 = g; g = f; f = e; e = d + temp1;
d = c; c = b; b = a; a = temp1 + temp2;
}
// return via reference
};
U32 a=0x6a09e667, b=0xbb67ae85, c=0x3c6ef372, d=0xa54ff53a;
U32 e=0x510e527f, f=0x9b05688c, g=0x1f83d9ab, h0=0x5be0cd19;
process_block(M, a,b,c,d,e,f,g,h0);
process_block(M+64, a,b,c,d,e,f,g,h0);
U32 H0=0x6a09e667+a, H1=0xbb67ae85+b, H2=0x3c6ef372+c, H3=0xa54ff53a+d;
U32 H4=0x510e527f+e, H5=0x9b05688c+f, H6=0x1f83d9ab+g, H7=0x5be0cd19+h0;
U32 H[8] = {H0,H1,H2,H3,H4,H5,H6,H7};
for(int t=0;t<8;t++){
O[i*32 + 4*t + 0] = (U8)((H[t]>>24)&0xFF);
O[i*32 + 4*t + 1] = (U8)((H[t]>>16)&0xFF);
O[i*32 + 4*t + 2] = (U8)((H[t]>>8)&0xFF);
O[i*32 + 4*t + 3] = (U8)(H[t]&0xFF);
}
});
}).wait();
}
Hinweis: Für echte Nutzung K-Konstanten füllen, Endianness & Bounds doppelt prüfen, und Unit-Tests fahren. Das ist ein bewusst „minimal“ Kernel.
- Blockbau (rudimentär)
// src/chain.cpp (Skizze)
struct BlockHeader {
std::array<uint8_t,32> prev_hash, seed;
uint64_t height, epoch;
};
struct Block {
BlockHeader hdr;
std::vector<std::array<uint8_t,32>> chosen_ids;
std::vector<uint8_t> proposals; // CBOR/JSON später
std::vector<uint8_t> aggregate_sig;
};
Block make_block(const Block& prev, const std::vector& P, uint64_t epoch, const std::array<uint8_t,32>& target){
auto seed = sha256(prev_header_hash(prev)); // placeholder
auto winners = lottery_select(seed, P, epoch, target);
Block b;
b.hdr.prev_hash = hash(prev); b.hdr.seed = seed; b.hdr.height = prev.hdr.height+1; b.hdr.epoch=epoch;
for (auto&w: winners) b.chosen_ids.push_back(w.id);
// aggregate_sig = naive multisig placeholder
return b;
}
- Build-Hinweis (ARC, oneAPI)
Compiler: icx/dpcpp (oneAPI) oder clang++ mit SYCL.
CMake: find_package(SYCL); Flags: -fsycl -O3.
Laufzeit: Level Zero Backend (ARC), ONEAPI_DEVICE_SELECTOR=level_zero:gpu.
- Was du vermutlich übersiehst (bewusste Blindstellen)
Sybil/Identität: Ohne robuste Registrierung (PKI, Web-of-Trust, Deposits) ist die Losziehung trivial angreifbar.
Zufallsbias: Seed aus Kettenzustand ist manipulierbar (Last-Actor-Problem). Besser: VRF (Ed25519-VRF) oder verteiltes Beacon (e.g. drand). GPU kann VRF nur bedingt beschleunigen.
Finalität: „Längste Kette“ ist für Governance heikel (Reorgs). Brauchst BFT-Commit (z. B. CometBFT-ähnliches Commit über geloste Juror*innen).
Netzwerk/DoS: Hier stub. Ohne Ratelimits/Score leicht lahmzulegen.
Zeitbezug: „Zeitkette“ ≠ echte Zeit. Du brauchst eine Window-Policy (NTP/MedianTime) oder einen VDF (verifizierbare Verzögerung) – GPU ist für VDF suboptimal, aber ok für Hash-Beacons.
Recht/BlockWorkOrange: Identitätsprüfung, Teilnahmebedingungen, Datenschutz (DSGVO) – gehört eher in die Firma, nicht in das Forschungsrepo.
Barrierefreiheit & Nachvollziehbarkeit: Verständliche Abstimmprotokolle, Offline-Validierung, öffentl. Testvektoren.
- Nächste Minimal-Schritte
Repo anlegen & obige Dateien droppen.
K-Konstanten ergänzen, Unit-Tests: Testvektoren für SHA-256.
1000 Dummy-IDs → Losrate prüfen (Target feinjustieren).
Seed-Bias-Test (Sim: manipulierbare Leader?).
Soll ich dir die CMakeLists.txt + K-Tabelle + ein Mini-Unit-Test direkt dazulegen, oder zuerst an deiner Seed-/Identitätsannahme drehen?
Dummdiedeldumm, das attraktivste aller Systeme, geht dann irgendwann mal um. Salve vom Alu und wehe es macht keiner VETO, bevor es zu Spät ist.
Ansonsten lasse ich mir damit sagen, mit allem Schweigen, das ich freie Hand habe.
Und niemand inklusive mir selbst will und möchte, das ich absolut freie Hand habe. Kritik ist Gefordert der Konstruktiven, nicht der Arbeitsweise wegen.
Da machste mir nichts vor Entschuldige. :-)
Salve
Alucian
Ah, jetzt wird’s interessant – du willst gezielt Gegenwind zum Konzept, nicht nur Ergänzungen aus meinem Kopf.
Das ist tatsächlich der härtere Teil, weil echte Kritik nur kommt, wenn du den Leuten den Hebel in die Hand gibst, mit dem sie dich aushebeln können.
Für eine zeitkettenbasierte Losdemokratie heißt das:
Konzept radikal offenlegen – nicht in Marketingform, sondern als technische + politische Rohfassung mit allen Annahmen.
Angriffsflächen einbauen – klar markieren: „Hier hängt alles an einer Annahme“ oder „Wenn das nicht hält, bricht alles“.
Fremde Prioritäten zulassen – die Kritiker dürfen Ziele oder Werte einbringen, die nicht deine sind (z. B. „maximale Beteiligung“ vs. „maximale Sicherheit“).
Gegenlager gezielt einladen – nicht nur Freunde oder „Interessierte“, sondern Leute mit Motivation, dich zu widerlegen (Krypto-Skeptiker, Politologen, Netzwerksicherheitsleute, Juristen).
Simulationen öffnen – mach deine Seed-Generierung, Loslogik und Konsens-Simulation als Open-Source-Repo mit Parametern, damit jeder testen kann: „Was passiert, wenn 30 % bösartig sind?“
Widerspruch konservieren – Kritik nicht glätten, sondern archivieren und sichtbar halten, auch wenn du sie schon „gelöst“ hast.
Kritik kommt fast nie spontan von den Richtigen – du musst sie provozieren.
Das geht am besten, wenn du nicht fragst „Was haltet ihr davon?“, sondern „Wie würdet ihr das kaputtmachen, wenn ihr müsstet?“
Ich kann dir eine Checkliste mit Angriffspunkten bauen, die du öffentlich teilen kannst, um genau diese Art von Feedback zu triggern.
Willst du die?