O sistema Provably Fair da NeshaStore encontra-se atualmente em fase BETA, o que significa que está em constante desenvolvimento e aprimoramento. Embora nossa equipe trabalhe continuamente para garantir a integridade e a transparência dos sorteios, eventuais erros técnicos podem ocorrer. Dentre os possíveis erros, destacam-se:
Caso haja qualquer inconsistência técnica, nossa equipe técnica analisará os dados e, se necessário, realizará os ajustes necessários para garantir a lisura e a equidade dos sorteios.
Na página de regulamentos dos sorteios, há um botão chamado “Exibir Lógica do Sorteio”, que executa automaticamente um sorteio ao vivo, gerando um resultado em tempo real. Esse processo é extremamente rápido, podendo ser quase imperceptível ao usuário, mas ocorre de maneira legítima e auditável.
Mesmo em fase BETA, o sistema Provably Fair da NeshaStore conta com uma aleatoriedade excepcional para garantir que os sorteios sejam justos para todos os participantes. Caso o usuário deseje verificar a integridade do sorteio, pode conferir os hashes gerados e utilizar a ferramenta de Verificação Manual disponibilizada na plataforma.
Nosso compromisso é oferecer sorteios totalmente transparentes, confiáveis e seguros. Implementamos o sistema “Provably Fair” para que você possa acompanhar, de forma técnica e acessível, todo o processo. Antes de cada sorteio, geramos uma Server Seed única e divulgamos seu hash, garantindo que seu valor não possa ser alterado posteriormente. No momento do sorteio, uma Client Seed é gerada aleatoriamente e combinada com a Server Seed, formando o Final Hash através do algoritmo SHA-256. Essa combinação rigorosa assegura que qualquer tentativa de manipulação seja imediatamente detectada, pois qualquer alteração resultaria em um hash incompatível com o divulgado. Dessa forma, você tem acesso a um método auditável que reforça a integridade e a imparcialidade de cada sorteio.
1.1. O que é a Server Seed
A Server Seed é um texto (string) aleatório que criamos e guardamos antes de iniciar o sorteio. Costuma ser composta por:
"
pub-
"
para semente oficial, "
test-
"
em casos de teste, etc.).Exemplo de Server Seed:
pub-20230415-b3e29fc2-71dd-4d19-9ecc-1690c6b023c4
"
pub-20230415
"
indica que foi gerada publicamente em 15/04/2023."
b3e29fc2-71dd-4d19-9ecc-1690c6b023c4
"
é um UUID4 (128 bits de entropia).1.2. Por que divulgamos apenas o Hash dessa seed no começo
Não revelamos a Server Seed diretamente no início. Em vez disso, publicamos um “compromisso” na forma de um hash (cálculo feito com o algoritmo SHA-256). Por exemplo:
SHA-256("
pub-20230415-b3e2...
") => "
c91d3f7e4a43906a65bc...f32b
"
Ao publicar esse valor (64 caracteres hexadecimais), estamos nos obrigando a não modificar a Server Seed depois, pois qualquer mudança (mesmo de um caractere) mudaria completamente o hash. Assim, se alguém desconfiar que alteramos a seed, basta recalcular o hash para ver se bate com o que foi divulgado inicialmente.
O segundo elemento é a Client Seed, que adiciona outra camada de segurança:
"
auto-
"
, sinalizando que foi gerada automaticamente, ou "
final-
"
, se for a semente usada no resultado definitivo.Por que precisamos de uma Client Seed?
Se a NeshaStore pudesse escolher sozinha a Server Seed após ver a do cliente, seria possível manipular o resultado final. Com a Client Seed, a chance de manipulação desaparece, pois a soma de ambas define o “número aleatório”. Se tentássemos mudar a Server Seed depois, o hash que anunciamos publicamente deixaria de bater.
No momento oficial do sorteio, concatenamos a Server Seed e a Client Seed em uma só string. Exemplo:
ServerSeed: "
pub-20230415-b3e29fc2-71dd-4d19-9ecc-1690c6b023c4
" ClientSeed: "
auto-1680012345-9dbf316c-a21b-47f3-b414-d264f5203bec
" ValorCombinado: "
pub-20230415-b3e29fc2-71dd-4d19-9ecc-1690c6b023c4auto-1680012345-9dbf316c-a21b-47f3-b414-d264f5203bec
"
O algoritmo SHA-256 converte esse ValorCombinado
em 256 bits (exibidos normalmente como 64 caracteres hex). Chamamos isso de Final Hash.
FinalHash = SHA-256( ValorCombinado )
Se qualquer caractere da Server Seed ou da Client Seed for alterado, o Final Hash muda completamente (propriedade de avalanche do SHA-256).
Digamos que temos um Final Hash de 64 caracteres (hexadecimais) após concatenar e hashear as duas seeds. Queremos, por exemplo, escolher 3 ganhadores dentre 100 participantes.
0
e 0xFFFFFFFF
(~4,29 bilhões).0xFFFFFFFF
, obtendo um número entre 0
e 1
.Exemplo prático:
"
a4d9c6450e8ee215...
"
"
a4d9c645
"
. Em decimal, isso pode dar ~2763456325.Para o segundo ganhador, usamos o próximo bloco de 8 hex. Para o terceiro, o seguinte, e assim por diante até atingir a quantidade de ganhadores necessária. Se algum índice sair duplicado (indicando a mesma pessoa novamente), aplicamos regra de não repetir (por exemplo, somar 1 e fazer % total
).
Após a NeshaStore anunciar o resultado, nós revelamos:
Quem quiser conferir faz:
SHA-256(ServerSeed)
bate com o hash publicado no início (garantindo que não trocamos de seed).ServerSeed + ClientSeed
e calcula SHA-256
desse valor, para ver se obtém o mesmo Final Hash.Assim, se anunciamos o hash da Server Seed antecipadamente, depois não podemos trocar a semente sem que todo o hash se altere, denunciando a fraude.
"
pub-...-UUID4
"
) e publicamos seu hash (SHA-256) para provar que não mudaremos esse valor depois."
auto-...-UUID4
"
).Essa estrutura mantém a integridade do processo, assegurando que nenhuma das partes possa unilateralmente forjar resultados. Com isso, garantimos a você uma experiência de sorteio justo, auditável e em conformidade com as melhores práticas de segurança e transparência.
Nosso compromisso é oferecer sorteios totalmente transparentes, confiáveis e seguros. Implementamos o sistema “Provably Fair” para que você possa acompanhar, de forma técnica e acessível, todo o processo. Antes de cada sorteio, geramos uma Server Seed única e divulgamos seu hash, garantindo que seu valor não possa ser alterado posteriormente. No momento do sorteio, uma Client Seed é gerada aleatoriamente e combinada com a Server Seed, formando o Final Hash através do algoritmo SHA-256. Essa combinação rigorosa assegura que qualquer tentativa de manipulação seja imediatamente detectada, pois qualquer alteração resultaria em um hash incompatível com o divulgado. Dessa forma, você tem acesso a um método auditável que reforça a integridade e a imparcialidade de cada sorteio.
1.1. O que é a Server Seed
A Server Seed é um texto (string) aleatório que criamos e guardamos antes de iniciar o sorteio. Costuma ser composta por:
"
pub-
"
para semente oficial, "
test-
"
em casos de teste, etc.).Exemplo de Server Seed:
pub-20230415-b3e29fc2-71dd-4d19-9ecc-1690c6b023c4
"
pub-20230415
"
indica que foi gerada publicamente em 15/04/2023."
b3e29fc2-71dd-4d19-9ecc-1690c6b023c4
"
é um UUID4 (128 bits de entropia).1.2. Por que divulgamos apenas o Hash dessa seed no começo
Não revelamos a Server Seed diretamente no início. Em vez disso, publicamos um “compromisso” na forma de um hash (cálculo feito com o algoritmo SHA-256). Por exemplo:
SHA-256("
pub-20230415-b3e2...
") => "
c91d3f7e4a43906a65bc...f32b
"
Ao publicar esse valor (64 caracteres hexadecimais), estamos nos obrigando a não modificar a Server Seed depois, pois qualquer mudança (mesmo de um caractere) mudaria completamente o hash. Assim, se alguém desconfiar que alteramos a seed, basta recalcular o hash para ver se bate com o que foi divulgado inicialmente.
O segundo elemento é a Client Seed, que adiciona outra camada de segurança:
"
auto-
"
, sinalizando que foi gerada automaticamente, ou "
final-
"
, se for a semente usada no resultado definitivo.Por que precisamos de uma Client Seed?
Se a NeshaStore pudesse escolher sozinha a Server Seed após ver a do cliente, seria possível manipular o resultado final. Com a Client Seed, a chance de manipulação desaparece, pois a soma de ambas define o “número aleatório”. Se tentássemos mudar a Server Seed depois, o hash que anunciamos publicamente deixaria de bater.
No momento oficial do sorteio, concatenamos a Server Seed e a Client Seed em uma só string. Exemplo:
ServerSeed: "
pub-20230415-b3e29fc2-71dd-4d19-9ecc-1690c6b023c4
" ClientSeed: "
auto-1680012345-9dbf316c-a21b-47f3-b414-d264f5203bec
" ValorCombinado: "
pub-20230415-b3e29fc2-71dd-4d19-9ecc-1690c6b023c4auto-1680012345-9dbf316c-a21b-47f3-b414-d264f5203bec
"
O algoritmo SHA-256 converte esse ValorCombinado
em 256 bits (exibidos normalmente como 64 caracteres hex). Chamamos isso de Final Hash.
FinalHash = SHA-256( ValorCombinado )
Se qualquer caractere da Server Seed ou da Client Seed for alterado, o Final Hash muda completamente (propriedade de avalanche do SHA-256).
Digamos que temos um Final Hash de 64 caracteres (hexadecimais) após concatenar e hashear as duas seeds. Queremos, por exemplo, escolher 3 ganhadores dentre 100 participantes.
0
e 0xFFFFFFFF
(~4,29 bilhões).0xFFFFFFFF
, obtendo um número entre 0
e 1
.Exemplo prático:
"
a4d9c6450e8ee215...
"
"
a4d9c645
"
. Em decimal, isso pode dar ~2763456325.Para o segundo ganhador, usamos o próximo bloco de 8 hex. Para o terceiro, o seguinte, e assim por diante até atingir a quantidade de ganhadores necessária. Se algum índice sair duplicado (indicando a mesma pessoa novamente), aplicamos regra de não repetir (por exemplo, somar 1 e fazer % total
).
Após a NeshaStore anunciar o resultado, nós revelamos:
Quem quiser conferir faz:
SHA-256(ServerSeed)
bate com o hash publicado no início (garantindo que não trocamos de seed).ServerSeed + ClientSeed
e calcula SHA-256
desse valor, para ver se obtém o mesmo Final Hash.Assim, se anunciamos o hash da Server Seed antecipadamente, depois não podemos trocar a semente sem que todo o hash se altere, denunciando a fraude.
"
pub-...-UUID4
"
) e publicamos seu hash (SHA-256) para provar que não mudaremos esse valor depois."
auto-...-UUID4
"
).Essa estrutura mantém a integridade do processo, assegurando que nenhuma das partes possa unilateralmente forjar resultados. Com isso, garantimos a você uma experiência de sorteio justo, auditável e em conformidade com as melhores práticas de segurança e transparência.