VictorTaelin/kindelia_presale_proposal_namespace_solution.md

## kindelia_presale_proposal_namespace_solution.md

      
    Raw
  

              kindelia_presale_proposal_namespace_solution.md
            
          
    Kindelia Presale Proposal

O problema

Nos últimos dias, temos discutido sobre como fazer um fund-raising bem-sucedido
e, principalmente, honesto para o Kindelia, considerando que a rede não possui
um token nativo, e que, mesmo se possuísse, fazer uma ICO atualmente traz
diversas implicações legais. Das diversas ideias levantadas, acho que uma boa
tenha sido proposta pelo Alex Van De Sande, porém, alguns aspectos da proposta
dele não são implementáveis. Eu realizei algumas alterações/otimizações na
ideia, e vou descrevê-la abaixo.
Atualmente, a rede Kindelia tem um problema, que, até então, postergamos. Todas
as funções globais da rede são identificadas por um ID de 60 bits, o qual a
gente usa para armazenar 10 símbolos de 6 bits; ou seja, o ID é interpretado
como um nome de 10 letras. O deploy de uma função é feito baseado nesse nome.
Isso gera um vetor de ataque social. Por exemplo, suponha que eu faça o deploy
das seguintes funções:
fun V.sha3 { ... } // minha implementação de sha3
fun V.cool { ... } // alguma função legal que eu fiz
fun V.gift { ... } // função que dá um presentinho aleatório pro caller
Tempos depois dessas funções se tornarem populares, alguém aleatório dá deploy em:
fun V.giveaway { ... } // função de um ser ruim, que faz sapecagens e maldades
O problema é que V. é usado como se fosse namespace, porém, ele não é. É só
parte do nome. Qualquer um pode deployar algo começando com V.. Para resolver
essa questão, a forma mais "elegante" seria um sistema de namespaces flexível,
feito usando contratos da própria rede. Porém, isso não é viável, porque a
lógica de deploy de função vem ANTES da existência de contratos. Por diversos
motivos, abrangendo segurança, robustez e performance da rede, é inviável
fazer com que a funcionalidade de deploy dependa de contratos na rede.
Sendo assim, a única alternativa viável seria um sistema de namespaces
nativo. Porém, isso traz 3 problemas:


Um sistema de namespaces completo é complexo. Considerando a simplicidade do
Kindelia, isso poderia dobrar ou até triplicar a complexidade do nó.


É quase certo que esse sistema precisaria de patches e ajustes, acabando com
o fator "zero core team" da Kindelia, o qual tanto trabalhamos para possibilitar.


Mesmo ignorando os fatores acima, um sistema de namespaces precisa de um
token para funcionar. Mas não há um token nativo!


A proposta a seguir resolve todos os problemas citados acima ao mesmo tempo, com
o mínimo de efeitos indesejáveis. É apenas um sistema de namespaces nativo,
porém bem simplificado, sem tokens, baseado em uma hierarquia de proprietários
de namespaces, que podem registrar sub-namespaces com um statement assinado.
A solução

A funcionalidade de deploy de funções será alterada da seguinte maneira:


Deploy de funções que não usam o caractere "." continuam como atualmente.
// não precisa de assinatura (nada muda)
fun do_stuff { ... }


Deploy de funções que usam um "." precisam ser assinadas.
// precisa de assinatura
fun Vic.Foo.bar { ... } sign { assinatura_aqui }
Tudo que vem antes do último "." é considerado o "namespace". Nesse caso,
Vic.Foo é o namespace. Para que o deploy seja aceito, é necessário que o
assinador seja dono desse "namespace".


Um novo statement, reg, é implementado para registro de namespaces.
reg Vic.Foo { endereço_do_dono } sign { assinatura_aqui }
Para que um registro de namespace seja bem-sucedido, é necessário que o
assinador seja dono do namespace anterior. Ou seja, o dono de "Vic" pode
registrar o namespace "Vic.Foo", e dá-lo a alguem (não necessáriamente o
próprio "Vic").


A rede ganha uma constante, ROOT_REGISTRAR, que pode registrar nomes raiz.
pub const ROOT_REGISTRAR = "0x0123456789abcdef0123456789abcdef01234567";
Somente essa entidade pode registrar nomespaces iniciais como Vic. ou Google..


Na nossa main-net, o ROOT_REGISTRAR é inicializado com o endereço da Fundação
Kindelia. Desse modo, a KF ganha um privilégio: ela é a única entidade capaz de
registrar root namespaces. Sim, isso vai contra o espírito da rede, porém, em
contraste com as alternativas consideradas, e com o Ethereum, que emitiu 72% dos
tokens para uma única entidade privada, essa proposta está bem na escala ética;
trata-se de poder centralizador relativamente irrisório. Além disso, é fácil, a
qualquer momento, executar um hard-fork para mudar o ROOT_REGISTRAR, enquanto é
obviamente impossível executar um que "apague" um pre-sale de token. Por fim,
usuários ainda podem registrar nomes sem "." como antigamente, então o sistema
de namespace é totalmente opcional.
Isso resolve os dois problemas citados de uma só vez, com o mínimo de poluição.
No problema exemplificado, basta que eu registre o nome "Vic" e faça deploys
nesse nome, impedindo que alguém se "passe por mim". Além disso, isso,
curiosamente, permite com que um mercado de nomes exista a nível de contrato.
Afinal, por mais que esse sistema seja parcialmente "hardcoded" no protocolo,
basta adicionar alguns IO novos, como ownr, para que usuários consigam usar
statements run{} para comprar e vender nomes.
run {
  !ownr 'NS.Bob'
  if ownr == MY_ADDRESS:
    !call ~ 'Coin' [{Send 1000 'NS'}]
  ...
} sign {
  bobs_signature
}

A transação acima faz com que "Bob" envie 1000 Coins para o NS, um hipotético
name registrar, caso ele registre o sub-nome "NS.Bob" para o próprio Bob. Assim,
basta Bob mandar essa transação pro dono do NS, que irá reservar o nome "NS.Bob"
para o Bob, e então coletar o pagamento.
O presale

Por fim, dado que nomes ganham um valor; e, principalmente, quanto menor o nome,
maior o valor (afinal, mais funções "cabem" nesse nome); isso nos permite fazer
um pre-sale de nomes, como NFTs. Podemos, por exemplo, fazer um contrato
Ethereum onde nomes são leiloados. Se esse pre-sale der certo, nomes curtos e
disputados, como "Love", vão receber bids altos. Os nomes que não forem vendidos
nesse primeiro momento, podemos vender futuramente. Desses leilões de nomes,
sairão os fundos para manter as operações da Kindelia Foundation,
indefinidamente. Ou até a comunidade nos "demitir", fazendo um hard-fork da
rede para mudar a constante ROOT_REGISTRAR.
Por fim, com isso, nenhum token da rede será influenciado por esse processo de
funding, de qualquer maneira. Então, por exemplo, se alguma entidade desejar
criar um token para servir como meio de troca, ou como asset escasso, dentro
da rede, essa entidade pode fazer isso usando de qualquer regra de emissão que
lhe convir. Essa proposta de funding evita a criação de qualquer tipo de token
oficial que precise ser "pre-mined".