Bitcoin XT, Forks e tudo mais (parte 2)

No post anterior eu expliquei o que eram os forks, e o que isso tinha a ver com o Bitcoin XT. Nesse post vou tentar esmiuçar um pouco o que é o Bitcoin XT.

Histórico

Desde os primórdios do bitcoin, o tamanho do bloco é o principal fator limitador da capacidade da rede de processar transações. No modelo atual, um bloco pode ter no máximo um megabyte de tamanho, o que limita o numero de transações a cerca de 7 por segundo 1)2). Hoje isso parece ser o suficiente, e a não ser em casos onde tentam fazer um “flood” na rede 3). Mike Hearn, o principal desenvolvedor do bitcoin XT fez estimativas usando o valor corrigido de 3,2 transações por segundo4) seria atingido ainda no primeiro semestre de 20165)6).

Dos piezas - on Flickr

Surgiram então ao menos 3 propostas de aumento dos blocos, defendidas por diferentes membros do “core developers”7). O Jeff Garzik criou o BIP 1008), que propunha um sistema de votação para aumento dos blocos e o BIP 102 9) que aumenta o bloco para 2Mb uma única vez. O Gavin Adresen propôs o BIP 10110), que propunha um aumento fixo inicial para 8Mb, dobrando esse tamanho a cada 2 anos até o limite de 20Mb. Por ultimo, o Pieter “sipa” Wuille fez uma proposta conciliatória11) que ficou conhecida como BIP “sipa” e não chegou a ganha numeração definitiva12). Essa proposta aumenta o blockchain gradualmente a cada 97 dias, numa média de 17.7% ao ano a partir de 2017. Os outros dois desenvolvedores do grupo13)14) se posicionaram contra o aumento do tamanho do bloco, por entre outros motivos15) acharem que forçar um hard fork sem consenso da comunidade seria arriscado.

Nesse contexto, a comunidade e os desenvolvedores não conseguiram entrar em consenso. O Gavin Adresen como lider nominal do grupo se sentia pressionado para que uma decisão fosse tomada rapidamente16). Aqui entra  em cena o Mike Hearn que já estava descontente com a forma como time de core developers tomava as decisões sobre o desenvolvimento do bitcoin e já vinha se desentendendo com alguns deles17). Ele então convenceu o Gavin Andresen a ajudá-lo em um novo projeto, construído em cima do Bitcoin Core, onde o processo de tomada de decisão fosse mais ágil e mais focado em atender as necessidades do usuário. O carro chefe desse novo projeto seria a BIP 101 do Gavin, mas ele comportaria outra mudanças. Em meados de agosto o projeto gerou seu primeiro fruto, que é o Bitcoin XT.18)

O que vem no pacote?

O Bitcoin XT, como o próprio projeto diz, nada mais é que uma série de patches aplicados ao Bitcoin Core para conduzi-lo na direção que os novos desenvolvedores, em especial o Mike Hear, acham correta19). O pacote completo de patches inclui, além do BIP 101, as seguintes funcionalidades:20)

  • Retransmissão de double spending pelos clientes (para facilitar a identificação de golpistas, a rede não mais filtrará as tentativas de gastar duas vezes a mesma moeda);
  • BIP 64 – “getutxos”, que permite que informações sobre transações sejam requisitadas na rede, auxiliando na implementação de carteiras descentralizadas e permitindo melhorias na interface;
  • Melhorias na lista de DNS seeds, permitindo maior diversidade e robustez nas conexões da rede;
  • Funcionalidades anti DoS – Duas propostas de proteção contra DoS, uma do Mike Hearn, outra do Tom Harding foram implementadas;

Votação e entrada em operação

O aumento de blocos não é uma mudança trivial, e não pode ser feito com uma mera atualização do software. É preciso forçar um hard fork na rede. Não existe uma forma de fazer a transição suave (usando soft forks), porque os blocos de tamanho maior seriam fatalmente rejeitados pelos clientes antigos, e não há uma maneira alternativa de encaixá-los no protocolo já que foi implementado como uma regra fixa em todos os clientes.21). Um hard fork é uma medida arriscada, que pode gerar prejuízos se feito apenas por uma parcela da rede. Normalmente ele é conduzido com o consenso da comunidade que atualiza os principais nós e clientes da rede antes de um prazo pré estabelecido. Entretanto a implementação do aumento de blocos ainda é um assunto polêmico, e o consenso nunca foi atingido. Então o Bitcoin XT se utiliza de um mecanismo de “votação” para mensurar o consenso da rede, e só após esse consenso ser atingido é que ele irá ativar as novas funcionalidades. Nesse meio tempo, ele opera exatamente igual a um cliente bitcoin core.

LuMaxArt Free Election 01

A votação tem uma regra bem simples: Após 11 de janeiro de 2016, se em algum momento 750 dos últimos 1000 blocos minerados (75%) forem marcados com o numero de versão do Bitcoin XT, o sistema considera que o consenso foi atingido.22) Uma mensagem pedindo a atualização da carteira para o XT é então enviada e exibida em todas as carteiras que ainda não foram trocadas pela versão XT, e após 2 semanas, as regras do XT passam a valer. Essa regra muda a dinâmica de obtenção de consenso de forma prévia para o que os autores do XT chama de “Economic majority voting”23), e é um dos principais pontos de crítica a forma como o projeto é conduzido 24)

Não existe Bitcoin XT, apenas Bitcoin

Em todas as discussões que acompanhei na internet o que mais tenho visto é a dificuldade de entender o que exatamente é o Bitcoin XT. Apesar da discussão ser complexa e cheia de nuances, termos tecnicos especificos do bitcoin como “fork”, “blockchain” e “broadcast de transações”, um ponto é bastante claro:

O Bitcoin XT e o Bitcoin são uma coisa só.

O bitcoin XT é uma carteira que implementa um conjunto de regras mais abrangente (blocos maiores), e por isso necessita de um hard fork para entrar em operação, mas ele não cria uma moeda paralela nem “mata” o bitcoin. Mudanças de regras no bitcoin sempre foram implementadas e nem por isso ele deixou de ser “bitcoin”. O bitcoin não deixa de existir, nem é substituído pelo XT. O XT apenas atualiza as regras de validação de blocos que o bitcoin usa, estabelecendo um novo consenso na rede, agora com blocos maiores25). A moeda continua sendo o bitcoin, a blockchain continua sendo a blockchain do bitcoin e a rede continua sendo a rede bitcoin. A expectativa dos desenvolvedores do XT é que o consenso seja atingido ainda durante  o período de duas semanas da atualização do XT e que no momento em que o primeiro bloco maior do que 1Mb for gerado, já não existam clientes desatualizados rodando na rede.26)

Existe uma controvérsia quanto ao que acontecerá se o defensores radicais do bitcoin core continuarem minerando e mantendo o bitcoin core vivo e conectado à rede. O próximo artigo irá focar nesse problema e em outros possíveis problemas do XT.

References

↑ 1. Bloco de 1Mb, 250 bytes por transação, um bloco a cada 10 minutos, ou 600 segundos, em média $$ \Rightarrow \frac{1000000}{250 \times 600} \approx 6.66$$
↑ 2. A conta de 250 bytes por transação foi feita pelo próprio Gavin Andresen e postada aqui
↑ 3. referencia par ao flood de transações na rede
↑ 4. 3,2 transações por segundo é o limite atualmente aceito pois o tamanho médio de transações cresceu desde a previsão do Adresen, veja aqui
↑ 5. ver “Bitcoin’s seasonal affective disorder“, por Mike Hearn
↑ 6. Opinião pessoal do autor aqui, olhando o gráfico de tamanho médio dos blocos (e não de numero de transações, como o Hearn fez) vejo que o crescimento dele é sublinear – pode ter a ver com a variação sazonal que ele explica no artigo – e, a não ser durante os ataques de flood que podem ser mitigados de outras maneiras, não está nem perto de chegar no limite dentro de um ano. Veja nesse gráfico
↑ 7. Core developers é o nome dado ao time principal de desenvolvimento do bitcoin core
↑ 8. BIP 100, por Jeff Garzik
↑ 9. BIP 102, por Jeff Garzik
↑ 10. BIP 101, por Gavin Andersen
↑ 11. como traduzir “compromise”, meu deus?
↑ 12. BIP “sipa”, por Pieter Wuille
↑ 13. Posição do Gregory Maxwell
↑ 14. Posição do Wladimir J. van der Laan
↑ 15. Veja um resumo dos argumentos aqui
↑ 16. citação: “A lot of people are pushing me to be more of a dictator (like Mike) … that may be what has to happen with the block size. I may just have to throw my weight around and say this is what it’s going to be. If you don’t like it, find another project.”
↑ 17. sobre a discussão com o Wladmir J. van der Laan
↑ 18. Why is Bitcoin forking?, por Mike Hearn
↑ 19. citação: “Bitcoin XT is an implementation of a Bitcoin full node, based upon the source code of Bitcoin Core. It is built by taking the latest stable Core release, applying a series of patches, and then doing deterministic builds so anyone can check the downloads correspond to the source code.”
↑ 20. Veja a lista detalhada dos patches
↑ 21. ver 1 e 2 para mais detalhes
↑ 22. O andamento da votação pode ser acompanhado aqui
↑ 23. ver “economic majority voting“, no bitcointalk
↑ 24. o outro é a estrutura hierárquica de tomada de decisão
↑ 25. estou deliberadamente ignorando as outras mudanças introduzidas pelo XT pois elas não envolvem a blockchain nem o fork, apenas afetam a apresentação ou a conectividade dos clientes, e mesmo que não forem implementadas em carteiras alternativas, não impediriam o funcionamento correto delas
↑ 26. ver uma discussão sobre isso aqui

Bitcoin XT, Forks e tudo mais (parte 1)

Se você está querendo saber o que é Bitcoin @ wikipedia.org (en), esse artigo não é pra você. Se procura um posicionamento politico, também veio ao lugar errado. Esse artigo é sobre como funciona o mecanismo de consenso, e a bifurcação (Fork) que ocorrerá em consequência da adoção do Bitcoin XT.

O mecanismo de consenso e os forks

O Bitcoin se propõe a resolver um problema clássico da computação, conhecido como “Problema dos generais bizantinos Iterado”1). Esse problema pode ser resumido como sendo “buscar o consenso através de mensagens transmitidas por um meio inseguro”. Não vou entrar em detalhes aqui sobre como o consenso é atingido ou buscado, pois sairia do escopo desse artigo, mas basta saber que o objetivo do bitcoin é conseguir o consenso entre os participantes da rede. Quando esse consenso não é atingido, acontece  oque chamamos de “Fork“, ou bifurcação.

Nesse ponto quero deixar claro: um Fork na Block chain (database)|blockchain @ wikipedia.org (en) não tem nada a ver com um fork do código fonte. um Fork na blockchain pode acontecer sem haver fork no código fonte (e ja aconteceu algumas vezes antes por bugs no software do bitcoin core2) ). Forks no código fonte do bitcoin acontecem todo o tempo. São desenvolvedores criando novas criptomoedas concorrentes ou complementares ao bitcoin3). Note que esses forks sempre criam novas blockchains, começadas do zero. Ou seja, são forks do código fonte, mas não da blockchain.

Soft Fork

Voltando ao assunto. O consenso no contexto do bitcoin é definido pela blockchain. Ela nada mais é do que uma sequencia de blocos, estes compostos por transações, encadeados um ao outro através de assinaturas criptográficas4). Sempre que há uma divergencia entre mineradores, ou seja, quando conjuntos diferentes de transações são validados ao mesmo tempo formando blocos diferentes para a mesma posição da blockchain, acontece um fork. Esse tipo de fork é chamado de “soft fork“, e faz parte do mecanismo de obtenção de consenso.

Como a rede decide qual desses dois blocos vai ser mantido e qual será descartado? Simples. Quando o proximo bloco for minerado, apenas um dos dois terá sido “assinado” pelo minerador. Aquele que ficar de fora, se torna “órfão”. E se dois mineradores criarem dois novos blocos simultâneos, cada um assinando um dos antecessores concorrentes criados na rodada anterior? Apesar de pouco provável, será formado um fork de dois blocos, ou três, quatro, etc, blocos até o momento em que algum minerador conseguir minerar sozinho o próximo bloco, sem conflitos, e criar uma sequencia mais longa que a concorrente. Quando essa sequencia é criada, a rede atinge novamente o consenso, e essa nova blockchain, mais longa que a concorrente, é mantida e a sequencia concorrente de blocos é tornada órfã.

Blockchain com soft forks
Soft Forks. Os blocos roxos se tornaram órfãos.

O mecanismo de consenso então é sempre decidir pela sequencia mais longa de blocos. Soft forks são mecanismos temporários que permitem que duas versões concorrentes da blockchain disputem qual delas atingirá o consenso. Soft forks com mais de um bloco são raras, muito raras.

E órfãos são ruins! Ninguém gosta de órfãos5). Órfãos dão um prejuízo danado a quem os minera, pois gasta poder de processamento para encontrar um bloco que vai ser descartado pela rede e não vai gerar dividendos. A menos que se esteja tentando um ataque à rede, ninguém vai querer forçar a criação de soft forks na rede, pois o risco de tomar prejuízo é grande.

correção:

Estudando mais sobre o XT para o próximo artigo percebi que tem uma incorreção nessa seção, então volto pra corrigi-la. Quando eu falei de soft forks, eu cito apenas os forks involuntários da rede, mas o termo é usado de forma bem mais ampla que isso. Quando mudanças no protocolo são retro-compatíveis, isto é, não vão quebrar as regras das carteiras já existentes (por exemplo, se eu reduzo o tamanho dos blocos ao invés de aumentá-lo), isso é também chamado de soft fork. Os blocos gerados nas carteiras antigas podem ser rejeitados pelas carteiras novas, mas os blocos novos não serão rejeitados pela carteira antiga e a rede manterá sua consistência, com uma quantidade pequena de “orfãos”.

Hard Forks

Então chegamos no grande vilão do consenso: Os hard forks. Hard forks são quando alguma coisa impede que um consenso seja atingido.  Pode ser um bug no sistema, que cria blocos reconhecidos por algumas versões da carteira, mas não por outras. Esse tipo de bug já aconteceu mais de uma vez6). Pode também ser decisão do time de desenvolvedores, para acrescentar funcionalidades à moeda. Para evitar que um hard fork proposital tenha impacto na moeda, um consenso prévio entre desenvolvedores e usuários costuma ser buscado, e quando o hard fork acontece, estão todos (ou quase todos) com a versão correta da carteira e a cadeia “errada” é rapidamente descartada ou ignorada.

Exemplo de Hard Fork. A cadeia superior usa a versão antiga da carteira enquanto a cadeia inferior usa a versão nova. Como não houve consenso, duas cadeias paralelas se formam a partir do terceiro bloco.

Se órfãos já eram ruins, imagina um hard fork? é todo um ramo da blockchain que nunca vai virar o consenso. É a pior coisa que pode acontecer, e é motivo de morte para várias altcoins7).

A rede e a propagação das transações

Além da blockchain, outro componente primordial do bitcoin é a rede. O bitcoin forma uma rede P2P conectando cada carteira com uma quantidade razoável de outras carteiras, de forma que as mensagens entre uma e outra consigam percorrer toda a rede. De uma forma simplificada, as transações criadas por uma carteira são enviadas a todas as outras conectadas a ela. Cada uma dessas carteiras, por sua vez, retransmite as transações recebidas de uma carteira conectada para todas as outras, e assim sucessivamente, até que toda a rede tenha recebido uma copia daquela transação. OS blocos minerados passam pelo mesmo processo. A diferença é que as transações ficam armazenadas em uma memória temporária, e os blocos são armazenados na blockchain, de forma permanente.

Exemplo de redes com clientes de versões diferentes. A primeira totalmente conectada. Na segunda, as linhas vermelhas indicam que clientes de versões diferentes irão se desconectar. Na terceira e quarta vemos as redes isoladamente.
Exemplo de redes com clientes de versões diferentes. Na primeira uma rede totalmente conectada. Na segunda, as linhas vermelhas indicam os pontos onde clientes de versões diferentes irão se desconectar. Na terceira e quarta vemos as redes isoladamente.

Quando acontece um fork, seja ele soft ou hard, a transmissão das transações e blocos continua ocorrendo normalmente. Ou seja, forks não afetam a propagação de transações pela rede. No caso de um hard fork, entretanto, alguns blocos gerados por carteiras de versão diferente ou com bug vão ser descartados como inválidos, e não serão gravados. Em casos graves, as carteiras que insistirem em enviar blocos “inválidos” podem ser desconectadas. Em alguns casos, essa desconexão pode separar a rede em duas redes que não se comunicam. Chamamos isso de split. Mas na maioria dos casos, as redes continuam se comunicando, mas ignorando os blocos gerados pela outra rede. Quando há um split, criam-se efetivamente duas redes separadas, com duas blockchains separadas, praticamente como se existissem duas moedas separadas.

O bitcoin XT

Também não vou entrar em detalhes sobre quais são as melhorias propostas pelo Bitcoin XT ou se elas são boas ou ruins. Apenas pretendo descrever o que deve acontecer com a blockchain e com a rede bitcoin devido a sua introdução.

O bitcoin XT é um fork do código do bitcoin que pretende gerar um hard fork da blockchain do bitcoin caso sua aceitação passe do limite de 75%8). Após atingido esse limite ele emitirá uma mensagem para todos os clientes da rede informando que haverá um hard fork e dando o prazo de 2 semanas para que quem quiser possa adequar seus sistemas. Passadas duas semanas, o XT começará a minerar blocos seguindo as novas regras, gerando assim um hard fork.

Isso não seria um problema normalmente, já que o processo de consenso seria conduzido fora da rede e quando fosse finalmente colocado em prática o fork, todos os usuários já estariam com seus sistemas e carteiras atualizados. Só que isso não aconteceu. O XT optou por não passar pelo processo de obtenção de consenso fora da rede e usou esse novo  processo para decidir sobre a criação ou não do hard fork. Em termos práticos, o processo deixou de ser uma tentativa de consenso e passou a ser uma votação por maioria de 3/4 dos mineradores9).

A intenção dos criadores do XT é que, caso eles atinjam os 75%, todo mundo migre para o XT e o consenso seja atingido sem hard fork. Mas isso não necessariamente é verdade. Vou tentar descrever abaixo alguns dos cenários que podem acontecer.

1) Caminho Feliz sem XT

Esse é o cenário mais fácil de prever. O XT não obtém 75% dos mineradores, e tudo continua como está.

2) Caminho Feliz com XT

Esse cenário se dá com um consenso sendo atingido antes do término das duas semanas de adaptação. Nesse caso, todos migram par ao XT e quando o hard fork ocorrer, não haverá ninguém no lado “antigo” do fork, que morrerá rapidamente. O XT substitui o bitcoin totalmente. Esse cenário parece improvável dada a quantidade de pessoas defendendo o XT.

3) Hard Fork, mas o bitcoin “antigo” continua existindo.

Suponhamos que 20% dos mineradores optem por não migrar par ao XT. No momento do hard fork teremos a criação de duas moedas com um passado comum. Uma que chamarei de “core” e é minerada pelos que não migraram para o XT e outra que chamarei “XT”, minerada por quem optou pela mudança. Nesse cenário, existem diversas situações de risco e que podem causar problemas tanto para a rede como para os usuários.

Na próxima parte desse artigo eu vou tratar em mais detalhes desse cenário, que é o mais interessante tecnicamente.

 

References

↑ 1. ver Byzantine Generals @ wikipedia.org (en)
↑ 2, 6. ver os seguintes artigos: 1, 2 e 3 
↑ 3. Atualmente são tantos que a ferramenta de visualização do github nem permite ver o gráfico
↑ 4. Pra quem quer saber em melhores detalhes, um bloco precisa conter o hash do bloco anterior e ser validado por um processo conhecido como mineração, veja esse artigo (não técnico) ou esse (mais técnico)
↑ 5. No contexto de bitcoins, não tenho nada contra crianças que precisam de adoção
↑ 7. veja nessa lista de altcoins mortas quantas morreram por hard forks
↑ 8. O valor exato é de 750 blocos minerados pelo XT entre os últimos 1000 blocos minerados, ver BIP-0101
↑ 9. na verdade 3/4 do poder de processamento, já que mineradores mais “poderosos” terão mais influencia no voto

Fuçando a transparencia paulista

Acabei de colocar no meu programinha de navegar pelos dados da transparencia os dados do estado de São Paulo. O principal problema com SP é que eles divulgam os valores, mas não dizem de quando eles são. Procurei por todo canto, mas nada… Acabei “chutando” que eram dados de julho, mas tenho certeza que errei no chute.

A sim, e preciso agradecer aos “hackers” que extraíram os dados do site, pois ele não é machine readable. Se alguém souber quem são, e eles quiserem ser identificados, me falem que eu coloco os créditos pra eles aqui.

Enfim, estão aí. Divirtam-se!

Transparencia navegável

Coloquei no ar uma página em javascript que permite navegar pelos dados pré-processados do portal da transparência. A primeira tentativa tinha siso um sistema que calculasse as estatisticas em tempo real, mas não deu certo. Dado demais, o sistema não dava conta. Então o que eu fiz foi pré-processar os dados e publica-los em formato json. As paginas usam javascript para carregar esses dados e exibir de forma bonitinha. Links:

Essa separação entre militares e não militares tem dois motivos: os salários dos militares só estão disponíveis par ao mes de maio, e os dados divulgados no post anterior foram colhidos antes dos salários dos militares serem incluidos no portal da transparência. Os dados dos militares tem algumas peculiaridades que eu gostaria de discutir em outro post, como por exemplo o fato de as mulheres ganharem mais do que os homens, contrastando com o que ocorre entre os servidores civis.

Quem quiser os fontes dos programas usados para gerar as páginas, está no mesmo projeto do google code, em outro branch. (Versão atualizada)

Update:

Editei os links para  a versão nova do programinha.

Update sobre a fuçação

Galera,

A CGU botou no ar hoje arquivos mais completos do que eles disponibilizavam antes (naquele mesmo link que eu citei no post original), em formato CSV, e dentro dele tem até mais informações do que as que eu “roubava” via wget. Vou adaptar meus programas e scripts e posto aqui novamente. (Os arquivos todos agora tem ID, então vai facilitar pra montar um banco, basta importar!)

.

Fuçando a transparencia, parte 2

Ontem enquanto eu escrevia o post no blog eu percebi que os dados no site do portal da transparencia tinham sido atualizados. Então durante a noite (e boa parte do dia) de hoje eu fiz tudo de novo: baixei, extrai, gerei os bancos, etc. Com isso os valores das tabelas variam um pouquinho, a saber, na mesma ordem que elas ocorrem:

Nome Qtd. Média
BANCO CENTRAL DO BRASIL 4459 R$ 16.737,60
ADVOCACIA-GERAL DA UNIAO 7546 R$ 15.088,26
CENTRO NAC.TECNO.ELETRONICA AVANCADA S.A 7 R$ 14.374,32
CONTROLADORIA-GERAL DA UNIAO 2342 R$ 14.247,22
INSTITUTO DE PESQUISA ECONOMICA APLICADA 564 R$ 14.184,95
SUPERINTENDENCIA DE SEGUROS PRIVADOS 422 R$ 13.678,75
MINISTERIO DA FAZENDA 32596 R$ 12.487,48
EMPRESA DE PESQUISA ENERGETICA 8 R$ 12.402,34
AGENCIA NACIONAL DE AGUAS 328 R$ 12.379,99
COMISSAO DE VALORES MOBILIARIOS 564 R$ 12.352,41
EMPRESA DE TRENS URBANOS DE PORTO ALEGRE 13 R$ 11.327,64
AGENCIA NAC PETROLEO GAS NAT BIOCOMBUSTI 685 R$ 11.301,15
MINISTERIO DAS RELACOES EXTERIORES 1547 R$ 11.129,46
AGENCIA NACIONAL DE VIGILANCIA SANITARIA 1934 R$ 10.952,20
AGENCIA NACIONAL DE SAUDE SUPLEMENTAR 602 R$ 10.804,12
AGENCIA NAC. DE TRANSPORTES AQUAVIARIOS 331 R$ 10.773,54
DEFENSORIA PUBLICA DA UNIAO 790 R$ 10.728,50
AGENCIA NACIONAL DE ENERGIA ELETRICA 680 R$ 10.692,32
DEPARTAMENTO DE POLICIA FEDERAL 13653 R$ 10.629,33
EMPRESA BRASILEIRA DE PESQ. AGROPECUARIA 80 R$ 10.608,95

Dá pra ver que muita coisa que parecia “lixo” sumiu dali. Devem ter dado uma limpa no banco. De resto, pros órgãos grandes, a coisa variou muito pouco.

A segunda tabela ficou também quase idêntica, mas dá pra ver que temos um diretor a mais no bacen, variando a média em menos de 10 reais.:

Ordem Nome Qtd. Média
1 PRESIDENTE DO BANCO CENTRAL 1 R$ 26.723,13
2 PRESIDENTA DA REPUBLICA 1 R$ 26.723,13
4 DIRETOR SERVIDOR DO BANCO CENTRAL 5 R$ 26.544,65
7 MINISTRO DE PRIMEIRA CLASSE 56 R$ 23.849,09
8 MINISTRO DE ESTADO 28 R$ 22.932,80
10 MINISTRO DE SEGUNDA CLASSE 92 R$ 21.803,70
11 DELEGADO DE POLICIA CIVIL ESPECIAL 16 R$ 21.165,90
12 DELEGADO DE POL FEDERAL CLASSE ESPECIAL 401 R$ 20.920,50
14 TEC DE PLANEJ E PESQUISA-QUADRO SUPLEMEN 15 R$ 20.709,20
17 PERITO CRIMINAL FEDERAL CLASSE ESPECIAL 161 R$ 20.121,84
19 AUDITOR-FISCAL DA RECEITA FEDERAL BRASIL 11555 R$ 19.580,66
21 CONSELHEIRO 109 R$ 19.460,44
24 TECNICO DE PLANEJAMENTO 70 R$ 19.137,80
28 AUDITOR FISCAL DO TRABALHO 2993 R$ 18.764,91
29 ADVOGADO DA UNIAO 1663 R$ 18.649,92
32 ANALISTA DO BANCO CENTRAL 3588 R$ 18.430,96
34 PROCURADOR DO BANCO CENTRAL 197 R$ 18.286,05
36 PROCURADOR FEDERAL 4022 R$ 18.122,84
37 PROCURADOR DA FAZENDA 1972 R$ 18.100,70
38 TECNICO DE PLANEJAMENTO E PESQUISA 241 R$ 17.943,75

E por ultimo, os nomes, maiores salários:

Nome Conta Média
RICARDO 3554 R$ 8.329,88
EDUARDO 3154 R$ 8.185,49
MAURICIO 1371 R$ 8.118,06
MAURO 1185 R$ 8.112,45
SERGIO 3519 R$ 8.085,87
CELSO 925 R$ 8.013,91
MARCO 1860 R$ 7.983,56
ALEXANDRE 2922 R$ 7.973,82
MARIO 1858 R$ 7.969,51
FLAVIO 1526 R$ 7.943,72

mais numerosos:

Nome Conta Média
MARIA 31473 R$ 6.323,33
JOSE 23182 R$ 6.737,69
ANTONIO 10149 R$ 6.785,85
ANA 9114 R$ 6.370,03
CARLOS 8711 R$ 7.431,25
PAULO 8459 R$ 7.608,78
JOAO 8380 R$ 6.781,19
LUIZ 7963 R$ 7.530,64
FRANCISCO 7534 R$ 6.400,11
MARCELO 4283 R$ 7.933,87

menores salários:

 

Nome Qtd Média
CAMILA 760 R$ 4.270,70
DIEGO 681 R$ 4.611,94
PRISCILA 597 R$ 4.742,34
RAIMUNDA 601 R$ 4.841,21
ALINE 1288 R$ 4.937,33
ANDREIA 629 R$ 5.048,32
VANESSA 955 R$ 5.085,29
THIAGO 1245 R$ 5.088,57
FRANCISCA 1297 R$ 5.152,34
THAIS 501 R$ 5.202,00

Dá pra ver que em nenhuma tabela a mudança foi significativa, e não muda nada sobre as conclusões que tirei no outro post. Suponho que esses dados devam estar constantemente sendo atualizados, já que vem de um sistema online do governo, o SIAPE. Com isso, lotações de pessoas, erros nos nomes, etc, devem estar sendo corrigidos constantemente. Mais ainda com esse sistema no ar.

Fuçando a transparência

 

Acordando o blog depois de anos parado, o assunto de hoje é: Transparência.

O Governo Federal lançou recentemente no seu Portal da Transparência, um sistema que permite a consulta dos salários de todos os servidores. Polêmicas a parte (eu acho que os dados poderiam ser facilmente anonimizados, solucionando 90% dos pontos polêmicos e sem atrapalhar em nada), a ferramenta é bem pobrinha. Dá pra consultar servidor por servidor o quanto ele ganha. Tirando a curiosidade sobre autoridades específicas (presidente, ministros, etc), não serve pra absolutamente NADA! (Serve pra saber pra qual parente você vai pedir dinheiro emprestado e de qual parente você deve fugir pra não ter de emprestar, mas isso não tem PN a ver com transparência.). Do ponto de vista de transparência e utilidade pública, o portal deveria ter formas de se manipular e agrupar os dados, procurando padrões estranhos, anomalias, etc. Pra isso, ele não serve. Aí entra a fuçação (sic?)!

Baixar pra ter em mãos

Pra fuçar, é preciso ter os dados em mãos. Poder manipular, transformar, jogar pra cima, apertar, chamar de meu amor e tudo mais! Meu primeiro passo então nessa briga, foi de como obter esses dados. O site permite o download de uma parcela desses dados, basta clicar no link “baixar mais dados” logo acima da lista de nomes logo na primeira tela:
link de download do arquivo de servidoresSó que esse arquivo não inclui o mais importante, que são os valores, os salários propriamente ditos. Inclui somente os dados de lotação do servidor (órgão, cargo, funções ocupadas, etc). Isso, sozinho, não serve pra quase nada (só pra contar quantas pessoas tem em cada órgão, porcentagens de funções gratificadas, e umas coisinhas interessantes que eu vou colocar mais em baixo). Eu ainda precisava da outra metade dos dados, que não existem em arquivinho pronto pra baixar. Aí a começa a fuçação.

Com cuspe, com jeito e um pouquinho de wget

Os dados de salário ficam em uma página separada. Pra chegar nela, preciso clicar no nome da pessoa, abrindo assim a tela com os cargos que ela ocupa, depois clicar novamente no botão de Remuneraçãoe finalmente abre-se uma tela com os valores de salário, descontos, rendimentos eventuais, etc. Baixar uma por uma as quase 700 mil páginas não era comigo.

A primeira coisa que fiz foi tentar identificar um jeito de automatizar isso. Notei que na URL havia sempre um campo numérico do tipo: IdServidor=XXXXXXX. Opa, bom demais. Isso provavelmente é a chave desses registros no banco de dados, e deve ser um valor seqüencial. Fiz alguns testes e cheguei a conclusão que dava pra fazer! Dava pra baixar tudo usando esse ID. Só que esse “IdServidor” não aparecia no arquivo baixado. Eu ia ter de improvisar pra saber quais eram os valores válidos pra ele. Busca binária, descobri o primeiro valor em 1000000 e o ultimo em 1691091 [foot]parece que esse valor andou crescendo de lá pra cá, então vou ter de conferir e baixar tudo de novo[/foot]. Agora era só baixar usando wget:

 for ((i=1000000;i<1691092;i++))
     do wget 'http://www.portaltransparencia.gov.br/servidores/Servidor-DetalhaRemuneracao.asp?Op=1&IdServidor='${i} -O salario.${i}.html -o /dev/null &
     if [ $((i%100)) -eq 0 ]
         then echo "echo waiting for $i"
         wait;
     fi
 done

(note que eu rodo 100 processos em background pra aumentar o nível de paralelismo. na época o site estava bem lento, então foi necessário fazer isso. Agora já não sei como está e pode não ser a forma ideal).

Pronto, os dados estavam todos ali. Agora só precisava “extrair” eles dos htmls e transformar em algo mais processável.

e PERL, não se esqueça do PERL…

Pois é.. e toca analisar os htmls pra ver como os dados estão estruturados ali e depois fazer um parser, quanto mais meia boca melhor, afinal é PERL, pra cuspir esses dados em formato “de gente”. No caso, “de gente” era um CSV. O programinha em perl pra processar essa galerinha aí foi esse aqui ó: parse.pl. Nada de mais. Só espera pelas coisas certas nos lugares certos. Eu acabei optando por ignorar uma série de coisas como 13, férias, jetons, etc, e me ative só ao “importante”: salário bruto, “Abate Teto”, imposto, previdência e o salário líquido. Na verdade nem o líquido eu acho útil, já que ele inclui férias ou 13 de um monte de gente. Qualquer conta feita pelo líquido fica distorcida por causa desses pagamentos eventuais. No fundo, eu sempre olho pelo salário bruto menos o abate do teto (estritamente falando, é “mais”, porque já vem negativo) que é a conta que melhor dá uma idéia da situação das coisas.

 E pra juntar tudo?

Pois é… E pra juntar tudo? Agora tava na hora, eu tinha descobrir um jeito. Mas pra começar eu achei que colocando tudo num banco de dados ficaria mais fácil de achar um jeito de casar um arquivo com o outro. Foi mais fácil que eu pensava. O Mysql importa de arquivo csv. Criei toscamente as tabelas com todos os campos varchar(255), importei e fui fuçar. A primeira coisa que tentei foi pelo nome.  SELECT nome, COUNT(*) FROM salario GROUP BY nome HAVING COUNT(*) > 1 me deu uma péssima surpresa… cheio de gente com nome igual… Mas o CPF deles era diferente… Será? bora então!  SELECT nome, cpf, COUNT(*) FROM salario GROUP BY nome, cpf HAVING COUNT(*) > 1.

BINGO!

Nenhuma repetição! Usando o CPF mais o nome eu consigo identificar unicamente todos os servidores, e consigo “casar” uma tabela com a outra. Acrescentei logo um campo “id_servidor” na tabela de servidores e preenchi:  UPDATE servidor SET id_servidor = (SELECT id_servidor FROM salario WHERE salario.cpf = servidor.cpf AND salario.nome = servidor.nome);. Voilá! Temos as duas tabelas relacionadas e podemos brincar de fuçar!

Fuçar na mão, também não né?

Fiz um monte de queries, pensei num monte de coisas, mas a coisa tava começando a ficar chata e repetitiva. Resolvi sistematizar isso tudo num programinha. Como surgiu uma discussão sobre grails com uma galera na mesma semana, o povo querendo saber se valia a pena usar em produção, etc, resolvi fazer em grails uma aplicaçãozinha de fuçar os dados. Minha idéia seria que facilitaria minha vida usar hql/hibernate ao invés de SQL puro.

Ledo engano!

Hibernate e HQL se mostraram lentos demais pro que eu queria fazer. É muito dado, muita manipulação de conjuntos grandes. Muito group by, inner queries, etc. Enfim, não rolou. Acabei fazendo tudo em SQL e usando o grails só mesmo como plataforma pra jogar os dados na web de forma bonitinha. No final, joguei tudo pra dentro do grails mesmo. A importação dos CSVs, a validação dos dados, a denormalização (que eu não tinha feito quando era só no sql), e ainda fiz um passo extra de tokenização dos nomes, que vai ser útil mais pra frente. O fonte dele está disponível no google code. Basta rodar com “grails run-app” dentro da raiz dele e ele já te manda pra tela de carga dos dados no primeiro acesso. Daqui pra frente ignorem meu banco original descrito lá pra cima. Vamos usar o banco gerado pela aplicação grails, beleza?

O que eu achei?

Pouca coisa interessante saiu no começo. A pior delas foi descobrir que fiz besteira! O banco central é o órgão que, na média, melhor paga no governo federal (mentira, não tem os dados do legislativo e TCU ou senado provavelmente pagam ainda melhor). Tivesse continuado por lá, tava rico: a média salarial por lá é de R$ 16.734,28. Bem a frente da AGU e da CGU que são os próximos “grandes” na lista. Uma tabelinha abaixo com os 20 primeiros. Destaque pros que tem gente suficiente pra média ser significativa:

Órgão de Lotação Qtd. Média
EMPRESA BRAS. DE SERVICOS HOSPITALARES 2 R$ 26.723,14
CENTRO NAC.TECNO.ELETRONICA AVANCADA S.A 8 R$ 20.146,68
EMPRESA DE PESQUISA ENERGETICA 9 R$ 17.147,72
BANCO CENTRAL DO BRASIL 4483 R$ 16.734,28
EMPRESA DE TRENS URBANOS DE PORTO ALEGRE 12 R$ 15.310,35
NUCLEBRAS EQUIPAMENTOS PESADOS 10 R$ 15.108,61
ADVOCACIA-GERAL DA UNIAO 7547 R$ 15.093,39
CONTROLADORIA-GERAL DA UNIAO 2343 R$ 14.247,21
INSTITUTO DE PESQUISA ECONOMICA APLICADA 564 R$ 14.184,95
SUPERINTENDENCIA DE SEGUROS PRIVADOS 422 R$ 13.678,70
MINISTERIO DA FAZENDA 32606 R$ 12.487,78
AGENCIA NACIONAL DE AGUAS 328 R$ 12.379,99
COMISSAO DE VALORES MOBILIARIOS 564 R$ 12.355,82
AGENCIA NAC PETROLEO GAS NAT BIOCOMBUSTI 686 R$ 11.296,41
GOVERNO DO ESTADO DA BAHIA 1 R$ 11.179,36
MINISTERIO DAS RELACOES EXTERIORES 1549 R$ 11.119,07
EMPRESA BRASILEIRA DE PESQ. AGROPECUARIA 86 R$ 11.035,41
AGENCIA NACIONAL DE VIGILANCIA SANITARIA 1937 R$ 10.944,00
AGENCIA NACIONAL DE SAUDE SUPLEMENTAR 599 R$ 10.823,87
AGENCIA NAC. DE TRANSPORTES AQUAVIARIOS 331 R$ 10.773,54

Mas aí entra um probleminha: a Receita Federal nem aparece. São todos lotados como “Ministério da Fazenda”, (o que está certo, já que ela não é um órgão independente, mas uma secretaria do ministério). Dá pra ter uma idéia melhor de quem recebe mais pegando a descrição dos cargos:

Posição Nome Qtd. Média
1 PRESIDENTE DO BANCO CENTRAL 1 R$ 26.723,13
2 PRESIDENTA DA REPUBLICA 1 R$ 26.723,13
4 DIRETOR SERVIDOR DO BANCO CENTRAL 4 R$ 26.376,98
7 MINISTRO DE PRIMEIRA CLASSE 56 R$ 23.849,09
8 MINISTRO DE ESTADO 28 R$ 23.007,40
10 MINISTRO DE SEGUNDA CLASSE 92 R$ 21.803,78
12 DELEGADO DE POLICIA CIVIL ESPECIAL 16 R$ 21.165,92
13 DELEGADO DE POL FEDERAL CLASSE ESPECIAL 400 R$ 20.923,64
14 TEC DE PLANEJ E PESQUISA-QUADRO SUPLEMEN 15 R$ 20.709,22
17 PERITO CRIMINAL FEDERAL CLASSE ESPECIAL 161 R$ 20.121,84
19 AUDITOR-FISCAL DA RECEITA FEDERAL BRASIL 11556 R$ 19.581,05
21 CONSELHEIRO 109 R$ 19.460,44
24 TECNICO DE PLANEJAMENTO 70 R$ 19.171,38
28 AUDITOR FISCAL DO TRABALHO 2992 R$ 18.763,84
29 ADVOGADO DA UNIAO 1664 R$ 18.648,99
32 ANALISTA DO BANCO CENTRAL 3604 R$ 18.437,51
34 PROCURADOR DO BANCO CENTRAL 197 R$ 18.286,05
35 PROCURADOR FEDERAL 4023 R$ 18.126,87
37 PROCURADOR DA FAZENDA 1973 R$ 18.096,88
38 TECNICO DE PLANEJAMENTO E PESQUISA 241 R$ 17.943,75

Inclui uma coluna de “posição” porque eu tive de cortar um monte de cargos com poucas pessoas (uma ou duas na maioria das vezes) que não fazem muito sentido nesse contexto. Aí da pra ver que a galera do Banco Central ainda perde pra galera da Receita Federal, apesar de tar lá bem pertinho.

Uma coisa interessante de notar nessa tabela são os “ministros de estado”, que em princípio ganham o mesmo que o presidente da república ou o presidente do BC, mas que ali estão bem pra baixo. Fuçando um pouco a gente descobre que vários deles recebem R$ 0,00 pois atingem o teto com as remunerações originais deles (do legislativo ou de outras esferas de poder) que não aparecem na lista. E tem o Brizola Neto, que tomou posse durante o mês de maio e não recebeu o valor integral por isso.

Mas por enquanto é só fatos curiosos. Não tem nada de realmente interessante. Foi quando eu resolvi entrar pra numerologia e descobrir

Qual o significado do seu nome?

Pois é, quais nomes (ou sobrenomes) fazem as pessoas ganharem mais? Como eu fiz a tokenização dos nomes, dá pra agrupar por eles e descobrir. E aqui vai uma dica: se quiser que seu filho se dê bem no funcionalismo público, chame ele de Ricardo! (E nunca, mas nunca mesmo, chame sua filha de Camila). Na verdade, eu filtrei os 100 nomes mais comuns e peguei os maiores e menores salários médios entre eles:

Nome Qtd Média
RICARDO 3557 R$ 8.334,13
EDUARDO 3156 R$ 8.187,19
MAURICIO 1371 R$ 8.119,83
MAURO 1186 R$ 8.109,96
SERGIO 3523 R$ 8.090,30
CELSO 926 R$ 8.034,11
MARCO 1860 R$ 7.983,56
ALEXANDRE 2922 R$ 7.977,80
MARIO 1859 R$ 7.976,97
FLAVIO 1527 R$ 7.942,51

Comparando com os nomes mais comuns, que ficam perto da média geral:

Nome Qtd Média
MARIA 31476 R$ 6.324,43
JOSE 23187 R$ 6.740,67
ANTONIO 10156 R$ 6.789,10
ANA 9116 R$ 6.370,80
CARLOS 8715 R$ 7.432,78
PAULO 8462 R$ 7.608,24
JOAO 8382 R$ 6.782,20
LUIZ 7963 R$ 7.536,28
FRANCISCO 7538 R$ 6.403,44
MARCELO 4283 R$ 7.933,07

Dá pra se ver a importância de ser Ricardo! São quase R$ 2.000,00 a mais. E pra camila então, nem se fala:

Nome Qtd Média
CAMILA 761 R$ 4.268,22
DIEGO 682 R$ 4.606,43
PRISCILA 597 R$ 4.743,88
RAIMUNDA 602 R$ 4.851,35
ALINE 1288 R$ 4.937,33
ANDREIA 630 R$ 5.044,09
VANESSA 956 R$ 5.080,88
THIAGO 1245 R$ 5.088,57
FRANCISCA 1297 R$ 5.152,34
THAIS 501 R$ 5.202,00

Um Ricardo vale quase o dobro de uma Camila!

(Eu não sei explicar esses fenômenos, mas a predominância masculina no topo e feminina na base dão uma idéia de que sexo deve ter influencia no salário. Outro fator que parece relevante é a época em que o nome esteve na moda. Ricardos tendem a ser mais velhos que Camilas, o que os coloca em patamares maiores nos planos de carreira. Ainda devem ter outros fatores extra-numerologia pra explicar, quem tiver palpites verificáveis, poste nos comentários)

E o que falta?

Bom, isso tudo foi diversão. Falta encontrar algo de sério nisso tudo. Pra isso eu queria fazer um data-mining mais sério nos dados, mas me falta experiência. Tentei montar um BI no pentaho com os dados, mas ainda estou apanhando pra modelar bem esses dados. Principalmente o fato de ter várias pessoas com mais de um cargo me deixa sem saber como isso se modela num DW.

Num data-mining “manual” andei descobrindo uns padrões interessantes: Quando agrupo as pessoas por órgão e por nome/sobrenome, encontro vários casos de pessoas que estão no mesmo órgão, tem o mesmo sobrenome, em geral uma mulher e um homem, ele com cargo de direção, ela com uma função comissionada de assessoramento, mas com um salário mais alto que a média. Sem uma verificação mais profunda, não posso afirmar nada, mas parece que: ou os diretores se apaixonam pelas assessoras mais bem graduadas, ou eles conseguem encaixar suas esposas nos melhores cargos de assessoramento dos órgãos onde trabalham. Conhecendo o serviço público, vou chutar que é a segunda opção!

Livros da semana

Bom terminei 3 livros essa semana, um eBook e 2 de quadrinhos.

Dead Until Dark

[amazonify]B003P9WR4A:right[/amazonify] O primeiro livro da série Southern Vampire Mysteries @ wikipedia.org (en) da Charlaine Harris @ wikipedia.org (en), que deu origem a série de TV True Blood @ wikipedia.org (en). No começo era uma forma de experimentar ler eBooks no celular (android, rodando o software do kindle). Mas o livro é fácil e empolgante. A narrativa em primeira pessoa dá uma visão mais “pessoal” da história do que o seriado. É mais previsível que na TV, mas tem uma riqueza de detalhes que só um bom livro pode dar. Recomendo muito pra quem gosta de vampiros ou da própria série True Blood. A linguagem é típica de best-seller, e a leitura flui bastante. Bom pra uma tarde de diversão.

MSP: Maurício de Souza por 50 artistas

[amazonify]B001FB4W0W:right[/amazonify] Ganhei este livro da minha irmã. São histórias curtas ou as vezes apenas um simples charge, escritas por diversos autores em homenagem aos 50 anos de carreira do Maurício de Souza @ wikipedia.org (en). Confesso que não sou muito fã dele mesmo não, mas sei o que ele representa pro quadrinho nacional. As histórias giram muito em torno dos mesmos tempos, muitas falando diretamente do aniversário de carreira do Maurício. O astronauta também apareceu super-representado, não sei se pela característica futurista do personagem ele pareceu mais fácil de trabalhar pros autores de Sci-Fi, ou se foi pela flexibilidade do personagem… Enfim, exageraram 😀 A maioria é mesmo bobinha, mas algumas são fenomenais. Logo de cara o Laerte abre com a mesma genialidade de sempre! O fechamento, pelo Vitor Cafaggi, também não fica por menos. Lá dentro, as charges simples do Angeli, do Gustavo Duarte e Dalcio machado dão um show a parte. Enfim, vale muito a pena, com algumas estórias fenomenais, apesar de várias meio chochas no meio!

O chinês americano

[amazonify]1596433736:right[/amazonify] Esse também foi presente, dessa vez da Lígia e do Pedro, meus vizinhos e companheiros de cachorro. A Lígia teve de ler pro mestrado uma pancada de quadrinhos auto-biográficos, e esse foi um dos poucos que ela deixou de fora. Se arrependeu depois! Eu me arrependeria também de não lê-lo. Pra mim foi o grande motivo desse post: é simplesmente fantástico. O Gene Luen Yang @ wikipedia.org (en) tem arte é simples, num estilo que junta Genndy Tartakovsky @ wikipedia.org (en) e Laerte com um quê de realismo e que dá vontade de ler mais a cada quadrinho. O roteiro mistura a velha lenda chinesa do Rei Macaco @ wikipedia.org (en) com a adolescência conturbada de um filho de imigrantes, sobrevivendo em um mundo que faz questão de rejeitá-lo! Tudo isso com uma cadência e fluidez que prendem o leitor. Difícil é não ler de uma sentada só. Sem a menor dúvida é a melhor história em quadrinhos que já li esse ano.

Blog do girino

%d bloggers like this: