Uma conversa com Duncan Coutts, chefe de arquitetura técnica de Cardano sobre Haskell e entregar Shelley
Duncan Coutts tem sido um guia importante no caminho de trazer Cardano Shelley para a rede principal. Apoiantes de longo prazo da IOHK provavelmente são familiarizados com a sua marca de cabelo comprido e barba com inclinações para beber chá enquanto conversa sobre a descentralização em frente a um quadro. Recentemente ele sentou-se para uma entrevista onde fala do reinício de Byron, a rede de testes de Shelley Haskell e a conclusão do ciclo de desenvolvimento pré-Shelley. Coutts, que tem estado a trabalhar com a IOHK desde 2016, traz uma riqueza de conhecimento desde o trabalho com a linguagem de programação Haskell há quase 20 anos e ajudar a fundar a consultora Well-Typed.
Qual o teu papel na IOHK?
Sou arquiteto técnico chefe para o projeto Cardano e estou responsável pela conceção e implementação do nó. Isto significa que colaboro com as equipas de consenso, razão, redes, e outras coisas. Em última instância trabalho para trazer a toda a gente em torno da mesma conceção depois das conversas com os líderes das equipas. A conceção de Cardano é o produto do trabalho conjunto de muitos indivíduos a trabalhar em conjunto.
O que traz a linguagem de programação Haskell para Cardano?
Haskell é um facilitador. Torna mais fácil seguir uma abordagem em que acreditamos estar correto que é dirigido pela ciência de computadores. Sabemos como fazer as coisas devidamente; a ciência dos computadores diz-nos como. O que temos que escolher são as técnicas para assim o fazer. Haskell torna isso mais fácil.
É um bom encaixe para Cardano porque se adequa ao software de elevada garantia, definida por especificações que é vital para uma blockchain. Haskell ajuda-nos a encontrar formas sistemáticas de evitarmos erros. Na essência é uma ratoeira melhor.
Estás a trabalhar com Haskell há muito tempo. Como tens observado o horizonte de Haskell alterar enquanto linguagem de programação funcional?
Agora as pessoas levam a sério. Quando comecei enquanto estudante em 1999 pensava que Haskell era fantástico. Outros estudantes pensavam “Wow isso é totalmente impraticável. Como vais conseguir um emprego?”
Na altura, a programação funcional era apenas uma curiosidade académica. Não havia código pré-definido e não era legível por máquina, que significava que não era usado por um diverso conjunto de pessoas. Não havia as ferramentas, variedade de bibliotecas ou experiência. Isso mudou ao longo dos anos: as ferramentas melhoraram tal como as bibliotecas. IOHK ajudou a desenvolver a infraestrutura para construir e distribuir código aberto em Haskell e o número de bibliotecas explodiu em número. Isso, em conjunto com mais ensino e uma mudança gradual de atitude pela indústria significa que as pessoas agora levam mais a sério. Haskell não mudou muito, mas a indústria em torno sim.
O que foi a mudança maior do ponto de vista da indústria?
São duas coisas. A primeira são as atitudes que estão a mudar, ainda assim de forma lenta. As pessoas estão a mudar de opinião quanto ao que consideram ser uma escolha sensata para a linguagem de programação. Anteriormente tudo tinha que ser em C ou em Java ou talvez Python, mas com o tempo boas ideias têm progresso mesmo que isso demore algum tempo. Podes fazer muito progresso ao apenas reconhecer que uma boa ideia é de facto uma boa ideia. O pensamento convencional apanha desenvolvimentos importantes, mesmo que isso demore 10 ou 15 anos. A indústria não abraçou a programação funcional como um todo, mas programadores individuais já tomaram algumas ideias. Isso faz Haskell parecer menos radical.
Se virmos uma linguagem de programação como Rust, tem alguns bons sistemas de tipos de Haskell apesar de não ter as ideias da programação funcional. Mesmo agora, Java e C++ têm algumas das ideias da programação funcional, assim Haskell não está assim tão longe do convencional conforme era.
A segunda maior mudança foi em termos de desempenho, que é muito melhor. Recentemente tornou-se competitivo com Java em termos de desempenho. Isto faz com que algumas pessoas digam “Wow, Haskell é tão rápido”, mas isso é porque comparam-no a Python ou a PHP do que a C. Por isso, é outra forma de dizer que Haskell melhorou ligeiramente, mas o ambiente na indústria em seu redor também mudou.
Estiveste muito envolvido no reinício de Byron que arrancou a semana passada. Porque foi este trabalho tão importante?
O reinício de Byron foi o culminar de 18 meses de trabalho árduo de múltiplas equipas de desenvolvimento da IOHK e constitui a revisão total da infraestrutura do nó com código 100% novo. O reinício introduz uma conceção extensiva e modular do próprio nó, separando o consenso, o razão e as componentes da rede além de melhoramentos e novas funcionalidades no backend da carteira e explorador de Cardano.
Para utilizadores de Daedalus, o reinício de Byron ver-nos-á a mover para uma cadência regular de atualizações [ver peça recente sobre Daedalus Flight para mais detalhes] depois da qual devem verificar que Daedalus se torna mais rápido, fiável e recorre a menos memória. No passado, muitos dos problemas encontrados pelos utilizadores de Daedalus eram devidos ao nó subjacente e não oriundos do Daedalus. O reinício de Byron irá melhorar muito estes aspetos e os utilizadores deverão ver Daedalus a sincronizar com carteiras existentes dentro de minutos mesmo enquanto descarregam a blockchain de Cardano.
Enquanto chefe de arquitetura, o teu papel é o de criar as fundações do futuro de Cardano. No que te tens focado para o alcançar?
O aspeto mais importante em relação à flexibilidade do futuro é manter as diferentes funções em separado. Uma das grandes melhorias do reinício de Byron é que as regras do razão serão totalmente independentes da implementação do consenso; esta modularidade significa que as regras do razão são funções matemáticas perfeitamente definidas, que é o aspeto essencial da programação funcional.
Como consequência, o resto é mais fácil, testar e alterar, quer agora quer no futuro. O algoritmo de consenso não está emaranhado com os detalhes das regras do razão assim, podemos alterar as regras do razão sem alterar a implementação do consenso. Isto torna a integração de Plutus e a funcionalidade de contratos inteligentes muito mais simples e também ajudará no futuro quando adicionarmos as características de tesouraria e de governação.
A implementação do próprio consenso foi também parametrizado de modo que possamos transitar do protocolo de consenso Ouroboros Classic para BFT e depois para Praos, que também fornece flexibilidade para futuras versões do protocolo que ainda não foram desenvolvidas.
Shelley é um grande passo em direção ao futuro de Cardano, mas qual o significado de compilar Haskell em JavaScript e WebAssembly?
Estamos interessados em compilar para JavaScript ou WebAssembly por causa de Plutus. Queremos que contratos em Plutus ou aplicações Plutus possam ser distribuídos aos utilizadores que incluiriam interfaces customizadas e lógica customizada para o utilizador em vez de para um servidor. Compilar para JavaScript permite-nos fazer isso; podes compilar código Plutus uma vez e distribuir aos utilizadores noutras plataformas.
Agradecemos ao Duncan Coutts pelo seu tempo. Enquanto chefe de arquitetura técnica ele é um pilar do projeto de Cardano e tem sido fundamental no sucesso da plataforma. Para mais entrevistas com a equipa mantém-te atento nos nossos canais sociais e no blogue da IOHK.