bsc
v1.4.15
O objetivo do BNB Smart Chain é trazer programabilidade e interoperabilidade ao BNB Beacon Chain. A fim de abraçar a comunidade popular existente e a tecnologia avançada, trará enormes benefícios ao permanecer compatível com todos os contratos inteligentes existentes nas ferramentas Ethereum e Ethereum. E para conseguir isso, a solução mais fácil é desenvolver baseado no fork go-ethereum, pois respeitamos muito o excelente trabalho do Ethereum.
BNB Smart Chain inicia seu desenvolvimento baseado no fork go-ethereum. Então você pode ver muitas ferramentas, binários e também documentos baseados em Ethereum, como o nome “geth”.
Mas a partir dessa linha de base compatível com EVM, o BNB Smart Chain introduz um sistema de 21 validadores com consenso de Prova de Autoridade Estacada (PoSA) que pode suportar tempos de bloqueio curtos e taxas mais baixas. Os candidatos a validadores de staking mais vinculados se tornarão validadores e produzirão blocos. A detecção de sinal duplo e outras lógicas de corte garantem segurança, estabilidade e finalidade da cadeia.
A Cadeia Inteligente BNB será:
Mais detalhes no Livro Branco.
Embora a Prova de Trabalho (PoW) tenha sido aprovada como um mecanismo prático para implementar uma rede descentralizada, ela não é amigável ao meio ambiente e também requer um grande número de participantes para manter a segurança.
A Prova de Autoridade (PoA) fornece alguma defesa contra ataques de 51%, com maior eficiência e tolerância a certos níveis de jogadores bizantinos (maliciosos ou hackeados). Entretanto, o protocolo PoA é mais criticado por não ser tão descentralizado como o PoW, uma vez que os validadores, ou seja, os nós que se revezam para produzir blocos, têm todas as autoridades e estão sujeitos a corrupção e ataques de segurança.
Outras blockchains, como EOS e Cosmos, introduzem diferentes tipos de Prova de Participação Adjunta (DPoS) para permitir que os detentores de tokens votem e elejam o conjunto de validadores. Aumenta a descentralização e favorece a governação comunitária.
Para combinar DPoS e PoA para consenso, o BNB Smart Chain implementa um novo mecanismo de consenso chamado Parlia que:
O BNB será executado no BNB Smart Chain da mesma forma que o ETH é executado no Ethereum, para que permaneça como native token do BSC. Isso significa que o BNB será usado para:
gas para implantar ou invocar Contrato Inteligente no BSC Muitos dos itens abaixo são iguais ou semelhantes ao go-ethereum.
Para pré-requisitos e instruções detalhadas de construção, leia as Instruções de instalação.
Construir geth requer um Go (versão 1.21 ou posterior) e um compilador C (GCC 5 ou superior). Você pode instalá-los usando seu gerenciador de pacotes favorito. Depois que as dependências estiverem instaladas, execute
make gethou, para construir o conjunto completo de utilitários:
make allSe você receber esse erro ao executar o nó com binário autoconstruído:
Caught SIGILL in blst_cgo_init, consult < blst > /bindinds/go/README.md.tente adicionar as seguintes variáveis de ambiente e compilar novamente:
export CGO_CFLAGS= " -O -D__BLST_PORTABLE__ "
export CGO_CFLAGS_ALLOW= " -O -D__BLST_PORTABLE__ " O projeto bsc vem com vários wrappers/executáveis encontrados no diretório cmd .
| Comando | Descrição |
|---|---|
geth | Binário principal do cliente BNB Smart Chain. É o ponto de entrada na rede BSC (rede principal, de teste ou privada), capaz de funcionar como um nó completo (padrão), nó de arquivo (retendo todo o estado histórico) ou um nó leve (recuperando dados ao vivo). Ele tem o mesmo e mais RPC e outras interfaces do go-ethereum e pode ser usado por outros processos como um gateway para a rede BSC por meio de endpoints JSON RPC expostos sobre transportes HTTP, WebSocket e/ou IPC. geth --help e a página CLI para opções de linha de comando. |
clef | Ferramenta de assinatura independente, que pode ser usada como assinante de back-end para geth . |
devp2p | Utilitários para interagir com nós na camada de rede, sem executar um blockchain completo. |
abigen | Gerador de código-fonte para converter definições de contrato Ethereum em pacotes Go fáceis de usar e seguros para tempo de compilação. Ele opera em ABIs de contrato Ethereum simples com funcionalidade expandida se o bytecode do contrato também estiver disponível. No entanto, ele também aceita arquivos fonte do Solidity, tornando o desenvolvimento muito mais ágil. Consulte nossa página de DApps nativos para obter detalhes. |
bootnode | Versão simplificada de nossa implementação de cliente Ethereum que participa apenas do protocolo de descoberta de nós de rede, mas não executa nenhum dos protocolos de aplicação de nível superior. Ele pode ser usado como um nó de inicialização leve para auxiliar na localização de pares em redes privadas. |
evm | Versão do utilitário de desenvolvedor do EVM (Ethereum Virtual Machine) que é capaz de executar trechos de bytecode em um ambiente e modo de execução configuráveis. Seu objetivo é permitir a depuração isolada e refinada de opcodes EVM (por exemplo, evm --code 60ff60ff --debug run ). |
rlpdump | Ferramenta utilitária para desenvolvedores para converter dumps RLP (prefixo de comprimento recursivo) binários (codificação de dados usada pelo protocolo Ethereum, tanto em rede quanto em consenso) em representação hierárquica mais amigável (por exemplo, rlpdump --hex CE0183FFFFFFC4C304050583616263 ). |
geth Passar por todos os sinalizadores de linha de comando possíveis está fora do escopo aqui (consulte nossa página CLI Wiki), mas enumeramos alguns combos de parâmetros comuns para que você aprenda rapidamente como executar sua própria instância geth .
O hardware deve atender a determinados requisitos para executar um nó completo na rede principal:
O requisito para testnet:
# Linux
wget $( curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest | grep browser_ | grep geth_linux | cut -d " -f4 )
mv geth_linux geth
chmod -v u+x geth
# MacOS
wget $( curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest | grep browser_ | grep geth_mac | cut -d " -f4 )
mv geth_macos geth
chmod -v u+x geth//== mainnet
wget $( curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest | grep browser_ | grep mainnet | cut -d " -f4 )
unzip mainnet.zip
//== testnet
wget $( curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest | grep browser_ | grep testnet | cut -d " -f4 )
unzip testnet.zipBaixe o snapshot mais recente do chaindata aqui. Siga o guia para estruturar seus arquivos.
./geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0
# # It is recommend to run fullnode with `--tries-verify-mode none` if you want high performance and care little about state consistency
# # It will run with Hash-Base Storage Scheme by default
./geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0 --tries-verify-mode none
# # It runs fullnode with Path-Base Storage Scheme.
# # It will enable inline state prune, keeping the latest 90000 blocks' history state by default.
./geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0 --tries-verify-mode none --state.scheme pathMonitore o log de ./node/bsc.log por padrão. Quando o nó iniciar a sincronização, você poderá ver a seguinte saída:
t=2022-09-08T13:00:27+0000 lvl=info msg= " Imported new chain segment " blocks=1 txs=177 mgas=17.317 elapsed=31.131ms mgasps=556.259 number=21,153,429 hash=0x42e6b54ba7106387f0650defc62c9ace3160b427702dab7bd1c5abb83a32d8db dirty= " 0.00 B "
t=2022-09-08T13:00:29+0000 lvl=info msg= " Imported new chain segment " blocks=1 txs=251 mgas=39.638 elapsed=68.827ms mgasps=575.900 number=21,153,430 hash=0xa3397b273b31b013e43487689782f20c03f47525b4cd4107c1715af45a88796e dirty= " 0.00 B "
t=2022-09-08T13:00:33+0000 lvl=info msg= " Imported new chain segment " blocks=1 txs=197 mgas=19.364 elapsed=34.663ms mgasps=558.632 number=21,153,431 hash=0x0c7872b698f28cb5c36a8a3e1e315b1d31bda6109b15467a9735a12380e2ad14 dirty= " 0.00 B " Inicie o console JavaScript interativo integrado do geth (por meio do subcomando console final) por meio do qual você pode interagir usando métodos web3 (nota: a versão web3 incluída no geth é muito antiga e não está atualizada com os documentos oficiais), bem como as próprias APIs de gerenciamento de geth . Esta ferramenta é opcional e se você deixá-la de fora, você sempre poderá anexar a uma instância geth já em execução com geth attach .
Mais detalhes sobre como executar um nó e se tornar um validador
Nota: Embora algumas medidas de proteção internas impeçam que as transações cruzem entre a rede principal e a rede de teste, você deve sempre usar contas separadas para jogar e para dinheiro real. A menos que você mova as contas manualmente, por padrão, geth separará corretamente as duas redes e não disponibilizará nenhuma conta entre elas.
Como alternativa à passagem de vários sinalizadores para o binário geth , você também pode passar um arquivo de configuração via:
$ geth --config /path/to/your_config.toml Para ter uma ideia de como o arquivo deve ficar, você pode usar o subcomando dumpconfig para exportar sua configuração existente:
$ geth --your-favourite-flags dumpconfiggeth Como desenvolvedor, mais cedo ou mais tarde você desejará começar a interagir com geth e a rede BSC por meio de seus próprios programas e não manualmente por meio do console. Para ajudar nisso, geth tem suporte integrado para APIs baseadas em JSON-RPC (APIs padrão e APIs específicas geth ). Eles podem ser expostos via HTTP, WebSockets e IPC (soquetes UNIX em plataformas baseadas em UNIX e pipes nomeados no Windows).
A interface IPC é habilitada por padrão e expõe todas as APIs suportadas por geth , enquanto as interfaces HTTP e WS precisam ser habilitadas manualmente e expor apenas um subconjunto de APIs por motivos de segurança. Eles podem ser ativados/desativados e configurados conforme o esperado.
Opções de API JSON-RPC baseadas em HTTP:
--http Habilita o servidor HTTP-RPC--http.addr Interface de escuta do servidor HTTP-RPC (padrão: localhost )--http.port Porta de escuta do servidor HTTP-RPC (padrão: 8545 )--http.api APIs oferecidas pela interface HTTP-RPC (padrão: eth,net,web3 )--http.corsdomain Lista separada por vírgulas de domínios dos quais aceitar solicitações de origem cruzada (aplicadas pelo navegador)--ws Habilita o servidor WS-RPC--ws.addr Interface de escuta do servidor WS-RPC (padrão: localhost )--ws.port Porta de escuta do servidor WS-RPC (padrão: 8546 )--ws.api oferecidas pela interface WS-RPC (padrão: eth,net,web3 )--ws.origins Origens das quais aceitar solicitações WebSocket--ipcdisable Desativa o servidor IPC-RPC--ipcapi APIs oferecidas pela interface IPC-RPC (padrão: admin,debug,eth,miner,net,personal,txpool,web3 )--ipcpath Nome do arquivo para soquete/pipe IPC dentro do datadir (caminhos explícitos escapam dele) Você precisará usar os recursos de seus próprios ambientes de programação (bibliotecas, ferramentas, etc.) para se conectar via HTTP, WS ou IPC a um nó geth configurado com os sinalizadores acima e precisará falar JSON-RPC em todos os transportes. Você pode reutilizar a mesma conexão para múltiplas solicitações!
Nota: Por favor, entenda as implicações de segurança de abrir um transporte baseado em HTTP/WS antes de fazê-lo! Hackers na Internet estão tentando ativamente subverter nós do BSC com APIs expostas! Além disso, todas as guias do navegador podem acessar servidores da Web executados localmente, portanto, páginas da Web mal-intencionadas podem tentar subverter APIs disponíveis localmente!
Bootnodes são nós superleves que não estão atrás de um NAT e executam apenas um protocolo de descoberta. Quando você inicia um nó, ele deve registrar seu enode, que é um identificador público que outras pessoas podem usar para se conectar ao seu nó.
Primeiro, o bootnode requer uma chave, que pode ser criada com o seguinte comando, que salvará uma chave em boot.key:
bootnode -genkey boot.key
Esta chave pode então ser usada para gerar um bootnode da seguinte forma:
bootnode -nodekey boot.key -addr :30311 -network bsc
A escolha da porta passada para -addr é arbitrária. O comando bootnode retorna os seguintes logs ao terminal, confirmando que está em execução:
enode://3063d1c9e1b824cfbb7c7b6abafa34faec6bb4e7e06941d218d760acdd7963b274278c5c3e63914bd6d1b58504c59ec5522c56f883baceb8538674b92da48a96@127.0.0.1:0?discport=30311
Note: you're using cmd/bootnode, a developer tool.
We recommend using a regular node as bootstrap node for production deployments.
INFO [08-21|11:11:30.687] New local node record seq=1,692,616,290,684 id=2c9af1742f8f85ce ip= udp=0 tcp=0
INFO [08-21|12:11:30.753] New local node record seq=1,692,616,290,685 id=2c9af1742f8f85ce ip=54.217.128.118 udp=30311 tcp=0
INFO [09-01|02:46:26.234] New local node record seq=1,692,616,290,686 id=2c9af1742f8f85ce ip=34.250.32.100 udp=30311 tcp=0
Obrigado por considerar ajudar com o código-fonte! Aceitamos contribuições de qualquer pessoa na Internet e somos gratos até mesmo pelas menores correções!
Se você gostaria de contribuir com o bsc, bifurque, corrija, confirme e envie uma solicitação pull para que os mantenedores revisem e mesclem na base de código principal. Se você deseja enviar alterações mais complexas, consulte primeiro os desenvolvedores principais em nosso canal discord para garantir que essas alterações estejam alinhadas com a filosofia geral do projeto e/ou obtenha algum feedback antecipado que pode tornar seus esforços muito mais importantes. mais leve, bem como nossos procedimentos de revisão e mesclagem rápidos e simples.
Certifique-se de que suas contribuições sigam nossas diretrizes de codificação:
master .Consulte o Guia do Desenvolvedor para obter mais detalhes sobre como configurar seu ambiente, gerenciar dependências do projeto e procedimentos de teste.
A biblioteca bsc (ou seja, todo o código fora do diretório cmd ) é licenciada sob a GNU Lesser General Public License v3.0, também incluída em nosso repositório no arquivo COPYING.LESSER .
Os binários bsc (ou seja, todo o código dentro do diretório cmd ) são licenciados sob a Licença Pública Geral GNU v3.0, também incluída em nosso repositório no arquivo COPYING .
