Block-Sena Technique du livre blanc
Sécurité et transparence

Auditable, tirage on-chain vérifiable par n'importe qui

En Block-Sena, le tirage utilise un processus en deux phases commit-reveal flux, combiné avec un futur blockhash et prevrandao. Cela rend le résultat déterminé après exécution, auditable sur la blockchain, et résistant à la manipulation manuelle des nombres tirés.

6 sur 30 Jeu de base avec 6 pioches uniques et un tirage de 6 numéros uniques
6 à 10 Billeterie à sélection multiple avec quotas de gains combinatoires (4/5/6 hits)
Multi-jeton Paiement par jeton avec règlement indépendant et carry-over vérifiable

Aperçu

Block-Sena est une loterie on-chain dans laquelle les achats de billets, le tour de verrouillage, l'exécution du tirage et le prix les distributions sont enregistrées sur la blockchain. Le protocole utilise un flux en deux phases : blockSenaPauseDraw (verrouiller la ronde et enregistrer l'engagement) et blockSenaDrawPay (révèle, tire et paie).

Mais

Garantissez un processus auditable et reproductible avec des règles de paiement transparentes pour chaque tour.

Auditabilité

N'importe qui peut vérifier les entrées (commit, salt, bloc cible), le calcul des valeurs de départ, les nombres tirés et les événements de règlement.

Commit-Révélation (2 phases)

Phase 1 : Pause + Engagement

La fonction blockSenaPauseDraw(usdValuePoolSnapshot, commitHash) verrouiller la ronde pour les nouveaux achats, définissez le futur bloc cible et stockez uniquement le sel secret hacher.

Phase 2 : Révélation + Tirage + Paiement

La fonction blockSenaDrawPay(sél) valider que keccak256 (sel) == commitHash, utilisez le bloc cible hachage de bloc, générer les 6 numéros uniques et exécuter les paiements.

Technique de fenêtre de blockhash

Le hachage de bloc ne peut être lu que pour environ 256 blocs. S'il expire, le tour a besoin d'un réinitialisation.opérationnelle. Cette réinitialisation est une sécurité intégrée rare avec un délai d'expiration de on-chain, et chaque utilisation reste publique on-chain.

Engagement du Sel (Salt)

commitHash = keccak256(abi.encodePacked(sel))
Le sel n'est pas révélé en phase 1. Seul le hash est public. Dans la phase 2, le sel révélé doit correspondre exactement au commit.

Bloc cible

targetBlock = bloc.numéro + 5
Le tirage utilise le hachage d'un futur bloc. Au moment de la validation, ce blockhash n'existe pas encore, donc personne ne connaît cette entrée à l'avance.

Draw Flow (21h00 UTC -> +5 blocs -> DrawPay)

Le flux opérationnel Block-Sena se sépare clairement clôture des billets depuis génération des 6 nombres. Cette séparation supprime le risque d'acheter des billets une fois que le résultat est connu ou en tentant d'ajuster les billets pour qu'ils correspondent aux numéros tirés.

1) 21h00 UTC (fenêtre opérationnelle) -> blockSenaPauseDraw

La fonction blockSenaPauseDraw(usdValuePoolSnapshot, commitHash) verrouille le tour, bloquer les nouveaux achats, enregistrer le commitHash, définir targetBlock = bloc.numéro + 5et stocke l'instantané du pool en USD.

2) Billets gelés avant que le hasard n'existe

Après PauseDraw, aucun nouveau ticket ne peut participer à cette tournée. À ce moment-là, blockhash(targetBlock) n'existe toujours pas, les 6 derniers chiffres ne peuvent donc pas encore être prédits ou calculés.

3) +5 blocs (après le bloc cible) -> blockSenaDrawPay

La fonction blockSenaDrawPay(sél) valide le sel par rapport au commit, lit le bloc cible hachage de bloc, génère les 6 numéros uniques et exécute paiements par jeton. Si elle est appelée avant le bloc cible, la transaction échoue (revert) on-chain.

4) Auditabilité publique à tout moment

Tout le monde peut vérifier dans l'explorateur : le blockSenaPauseDraw transaction, bloquable, le blockSenaDrawPay tx, sel révélé, les numéros tirés et les événements de règlement/paiement.

Ce que cette conception empêche en pratique

Ce n'est pas possible acheter un ticket après avoir vu les 6 numéros du tour, parce que le tour était déjà verrouillé blockSenaPauseDraw avant que le tirage au sort ne soit exécuté.

Ce n'est pas possible connaître les 6 chiffres au moment du verrouillage, car la formule dépend d'un futur bloc (bloquable) qui n'existe pas encore � ce moment-l�.

Ce n'est pas possible d'exécuter le tirage au sort avant le temps technique, car blockSenaDrawPay n�cessite on-chain que le bloc actuel ait d�j� d�pass� le bloquable.

À propos de ResetDraw (scénario rare)

blockSenaResetDraw n'existe que pour empêcher qu'un tour soit bloqué de manière permanente si une longue panne d'infrastructure se produit (par exemple : pannes RPC, maintenance de service, pannes de réseau/infra ou problèmes opérationnels prolongés) et DrawPay ne peut pas être exécuté avant blockhash(targetBlock) expirant.

Dans le flux normal, le comportement attendu est d'exécuter DrawPay quelques blocs apr�s PauseDraw (cible � +5 blocs). La réinitialisation est une sauvegarde de la vivacité, ne fait pas partie du flux de tirage normal.

Formule de tirage mathématique (6 nombres uniques)

La graine de tirage est dérivée de la combinaison d'un futur bloc, du sel engagé et des données rondes. � partir de l�, le contrat g�n�re des num�ros de 1 � 30, en supprimant les doublons jusqu'� atteindre 6 num�ros uniques.

En termes de sécurité opérationnelle : parce que les billets sont déjà gelés dans le PauseDraw phase avant que ce futur bloc n'existe, le tirage ne peut pas être "cr��" pour correspondre à un ticket inséré plus tard, et aucun participant ne peut parier dans le même tour après connaître le résultat.

Dessiner une graine

seed = keccak256(abi.encodePacked(blockhash(targetBlock), salt, block.prevrandao, roundId))
Intrants réels utilisés par le contrat : blockhash(targetBlock), sel, bloc.prevrandao, et currentRoundId.

Génération de chaque numéro

num = (keccak256(seed, nonce) mod 30) + 1
Si le numéro a déjà �t� tir� au cours de ce tour, il est �cart� et le occasionnellement est incrément�. Le processus se répète jusqu'à ce que 6 numéros uniques soient obtenus.

Cette procédure évite la répétition des numéros dans le résultat final et maintient le tirage au sort dans la plage valide. 1..30.

Important (transparence) Le résultat d'un tour finalisé est déterministe et reproductible avec les données on-chain. Tout opérationnel une tentative d'intervention (par exemple, une réinitialisation de ronde) laisse une trace publique et vérifiable on-chain.

Billeterie à sélection multiple (6 � 10 numéros) et quotas combinatoires

En Block-Sena, un ticket peut contenir de 6 à 10 numéros. Ce ticket représente plusieurs combinaisons équivalentes de 6 nombres. Le calcul du prix est basé sur quotas gagnants (combinaisons), pas seulement des « personnes ».

Combinaisons totales pour un ticket avec k numéros

combinaisons(k) = C(k, 6)
Exemple : si k = 10, alors C(10,6) = 210 combinaisons équivalentes.

Quotas de gains par niveau (4/5/6)

Envisagez un billet avec k des chiffres et x correspondant à l'intérieur des 6 numéros tirés.

q6 = C(x, 6)
q5 = C(x, 5) * C(k - x, 1)
q4 = C(x, 4) * C(k - x, 2)
Le contrat ajoute ces quotas par portefeuille et les paies sous une forme agrégée par jeton (plus économe en gaz).

Exemple (billet � 10 num�ros avec les 6 num�ros tir�s � l'int�rieur du 10)

q6 = 1, q5 = 24, q4 = 90. Le même ticket peut gagner simultanément dans les 3 niveaux.

Paiement multi-jetons (règlement par jeton)

Chaque jeton de piscine (par exemple, natif, USDC, USDT) est réglé selon le réglage. Le contrat calcule les gagnants et les prix par tour et par jeton, en conservant l'historique exact dans RoundTokenStats.

Répartition des niveaux

Hits niveau 6 = 80 % du pool de jetons
Hits niveau 5 = 15 % du pool de jetons
Hits niveau 4 = 5 % du pool de jetons

Prix ​​par quota de gagnants

prizePerWinnerX = étage (prizeBucketX / quotasX)
La division utilise l'arithmétique entière on-chain. Les restes d'arrondi (poussière) restent sous la forme carry-over pour le tour suivant.

S'il n'y a pas de gagnants

Le montant de ce niveau n'est pas perdu : il devient carry-over pour ce jeton au tour suivant.

S'il y a plusieurs gagnants

Le prix est divisé par quotas de gains. Un même portefeuille peut recevoir plusieurs quotas regroupés en un seul paiement par token.

Comment auditer un tour (étape par étape)

  1. Trouver le blockSenaPauseDraw tx et note le commitHash et bloquable.
  2. Après le bloc cible, trouvez le blockSenaDrawPay tx et lisez le soumis sel.
  3. Recalculateur keccak256(sel) et confirmez qu'il correspond au commitHash.
  4. lires blockhash(targetBlock) dans l'explorateur et le prevrandao du bloc draw tx.
  5. Reproduire la graine et la routine de génération de 6 nombres (en supprimant les doublons) et comparer avec DessinerExécuté.
  6. Si une panne opérationnelle rare se produit, inspectez DrawReset (roundId, targetBlock, reset block) pour valider le délai d'attente et réinitialiser la traçabilité.
  7. Vérifier RoundTokenSettled événements pour les pools, les paiements par niveau et par jeton carry-over.
  8. Confirmez les transferts natifs/ERC20 pour valider les paiements aux gagnants.

Garanties, transparence et limites opérationnelles

Block-Sena a été conçu pour qu'un résultat rond soit vérifiable, reproductible et transparent. La révélation de validation combinée à un futur bloc réduit considérablement la possibilité de manipulation manuelle des résultats.

En termes techniques, le modèle donne le résultat imprévisible au moment du verrouillage, car le tour est clôturé avant le blockhash(targetBlock) utilisé dans la graine existe. Cela maintient la formule publique et vérifiable sans autoriser des paris ultérieurs basés sur le résultat.

Ce qui est garanti on-chain

Règles de dessin, calculs de quotas, répartition des paiements par niveaux (80/15/5), historique par jeton, événements et traçabilité de chaque étape.

Opération d'urgence

Il existe une fonction de réinitialisation du tirage pour les scénarios techniques rares (par exemple, l'expiration du blockhash provoque par panne prolongée de l'infra/du réseau). Il ne peut être exécuté qu'avec le tour verrouillé et après on-chain timeout. Chaque utilisation est publique, enregistrée on-chain et auditable dans l'explorateur.

La réinitialisation ne déplace pas les fonds, ne supprime pas les tickets et ne modifie pas le pool. Il déverrouille uniquement le cycle rond pour permettre une nouvelle tentative de tirage au sort pour le même tournée dans un scénario d’échec rare.

Les fonds des prix restent dans le contrat jusqu'au tirage au sort et aux paiements automatiques aux gagnants. S'il n'y a pas de gagnants dans un niveau, la valeur reste comptabilisée comme carry-over pour le tour suivant. Le propriétaire n'a pas de fonction pour retirer les fonds déjà comptabilisés dans la cagnotte.

Le rescueAll la fonction n'existe que pour sauver excédent non comptabilisé (par exemple, transferts directs erronés), calculez solde réel - pool enregistré. Il n'atteint pas les fonds des prix représentaient déjà le pool.

En d autres termes�: Block-Sena ne demande pas de confiance aveugle. Il délivre un flux observable, reproduit mathématiquement et v�rifi� on-chain par quiconque � tout moment.