fccoelho/curso_blockchain

Indtroductory course to cryptocurrencies and applications of Blockchain technologies.

curso_blockchain's Issues

Entrega da A1: pool de manuscritos esperando revisão

Plano de trabalho

Tema: pool de manuscritos esperando revisão.

Objetivo

Para esse trabalho, o objetivo é desenvolver um pequeno sistema no qual seja possível realizar operações relacionadas a manuscritos que ainda necessitem de revisão. I.e., deve haver a opção de autores poderem enviar seus manuscritos para revisão e de revisores poderem listar e avaliar os manuscritos a espera de revisão.

Estratégia

Na versão atual do DPublish, existe o contrato DPublish, que serve como um repositório de manuscritos, ligando o ID de um manuscrito ao endereço de seu autor. Dessa forma, conseguímos ter uma forma geral de acessar os manuscritos já publicados.

No entanto, é necessário saber quais manuscritos ainda não receberam uma revisão. Para isso, a partir de um contrato que irá implementar o sistema de revisão, podemos consultar quais manuscritos já receberam revisão ou que tiverem revisões avaliadas como válida.

De qualquer forma, é importante que possamos acessar esse conjunto de dados de uma maneira performática. Dado isso, podemos considerar duas estratégias diferentes:

1. Para cada nova chamada ou mudança no contrato DPublish, guardar em um novo contrato o ID dos novos manuscritos, ao mesmo tempo que associa a eles a informação de que ainda não foram revisados. Além disso, também devemos ouvir o contrato que vai implementar a revisão dos manuscritos, verificando se a regra que avalia se um manuscrito ainda espera revisão foi satisfeita para algum dos que ainda não possuem revisão, e modificar seu valor.
2. No próprio DPublish, associamos a cada ID de uma publicação uma estrutura de dados que vai conter o endereço do publicador e seu status de revisão. Ou seja, modificamos o mapping que existe atualmente para que possa guardar mais dados. Além disso, o contrato que irá implementar revisão deve modificar a variável que indica se o manuscrito está revisado diretamente no contrato DPublish.

Essas duas estratégias possuem suas vantagens e desvantagens. Uma vantagem da primeira estratégia é sua implementação quase indolor, sem precisar modificar diretamente outros contratos. A vantagem da segunda estratégia é ter um menor uso de recursos no geral, pois não duplicamos o ID dos manuscritos ou realizamos manipulações muito elaboradas.

Uma vez que alguma das estratégias for implementada, temos que a opção de publicar um manuscrito para revisão é feita de forma automática, assim que um pre-print é disponibilizado.

Porém, ainda seria necessário uma interface mais amigável para a consulta dos manuscritos, que pode ser feito em Python e disponibilizado via uma REST API ou diretamente em uma interface web para uso final pelos autores e revisores.

Requisitos

O requisito central desse trabalho é a criação de um contrato de revisão. Sua implementação e interface vão ter bastante influência em como o sistema de manuscritos esperando revisão vai ser feito.

Em quesito de viabilidade, temos situações diferentes para cada uma das estratégias. A primeira necessita que o Solidity ofereça a possibilidade de trabalhar com eventos e observadores na escala proposta. Já a segunda requer que haja um esforço coordenado na criação de um bom design dos contratos a serem usados nesse trabalho a fim de garantir que as regras de negócio sejam bem implementadas em cada um deles.

Cronograma

A priori, o cronograma da realização desse trabalho se baseia no tempo de desenvolvimento dos outros contratos (modificações no DPublish, criação do contrato de revisão, etc.). Mas, uma vez isso resolvido, os seguintes passos serão seguidos:

1. Estudo e planejamento da implementação da estratégia escolhida.
2. Implementação, desenvolvimento e modificação dos contratos para atender as especificações.
3. Desenvolvimento de uma interface web.

Entrega A1: Desenvolver método de determinar editores

Plano de trabalho - Implementar método para determinar editores

Introdução

O objetivo desse projeto é criar um método para determinar os editores, seguindo as especificações desse artigo, na plataforma Dpublish.

Estratégia

Os editores serão utilizadores de extrema importância para o projeto, pois são revisores que tem com maiores avaliações, e isso pode implicar em mais benefício nos contrato. Serão definidas métricas para a alterar o status de um revisor para editor, que serão o número de revisões já feitas e a média de suas avaliações, pois além de ter uma boa avaliação o revisor precisa de experiência, não devemos ter um revisor que acabou de entrar na plataforma com uma avaliação máxima e já se tornar editor, por exemplo. Não irei alterar os revisores para editores, pois eles têm a mesma função além do editor ter mais benefícios, então só irei adicionar ao revisor o status de revisor como um booleano, para indicar se é ou não editor.

Requisitos

• O método de avaliação de revisão já deve estar criado.
• O métodode publicação de revisão já deve estar criado.

Cronograma

• Entrega do Plano de Trabalho(25/09)
• Estudo do contrato Dpublish(30/09 a 07/10)
• Desenvolvimento do projeto(07/10 a 28/11)
• Validação e testagem das implementações (11/11 a 21/11)
• Entrega do projeto (28/11)

Apresentações

Calendário de Apresentações

• Ethereum 2.0
• Litecoin
• Cardano
• Dogecoin
• Polkadot
• Stellar
• Zcash
• Monero
• Theter
• Ripple (XRP)
• Binance coin
• Bitcoin cash
• Theta
• Filecoin
• TRX
• Dai

Dúvidas - CubeHash

Professor, não faço a menor ideia de como progredir.

In these notebook, as part of the course at https://github.com/fccoelho/Curso_Blockchain, ministered by professor Flávio Codeço Coelho, I will implement CubeHash, a cryptographic hash function.

`i=10
r=10
b=10
f=10
h=24
m="secret password"

import numpy as np

if b>128:
print("b must be smaller then or equall to 128")
elif np.remainder(h,8)!=0 or (h/8)>64:
print("h must be a multiple of 8 and smaller then 512")
else:
print("CubeHash"+ str(i) + "+" + str(r) + "/" + str(b) + "+" + str(f) + "-" + str(h))

`

Entrega da A1: Front-End e ambiente de testes

Plano de Trabalho

---

Introdução

Plano de trabalho para desenvolvimento da interface que permitirá aos usuários do Decentralized Autonomous Publishing House - DAPH, projeto a ser realizado pela turma na A2, realizar interações com o software de maneira agradável.

---

Objetivo

O objetivo será preparar as telas por onde os usuários farão contato com os componentes do projeto. Sendo assim, meu foco será no front-end e sua elaboração para interagir com o back-end da aplicação.
Grande parte do desenvolvimento será focado em acompanhar as necessidades de interação com o usuário para cada componente do software sendo feito e verificar os requisitos de experiência dos clientes, garantindo que seja viável que qualquer possível objetivo de um utilizador do software seja atendido pela interface de maneira eficiente.
Para agilizar o desenvolvimento do projeto como um todo, parte do objetivo estará em disponibilizar, quando necessário, uma interface gráfica para possibilitar uma area de teste para os demais desenvolvedores e permitir que eles foquem nas suas tarefas primárias.
Para tal, será necessário munir o projeto com uma interface principal que guiará o usuário para as diferentes áreas, e preparar um tema a ser compartilhado por todas as interfaces para manter uma consistência visual.
Além disso, será responsabilidade do Front-end realizar algumas verificações iniciais e algumas restrições para ações que alguns tipos de usuário recebam um feedback diferente da aplicação.
Assim também será realizado implementações de algumas restrições no backend para alguns casos, por exemplo, analisar restrições como a não possibilidade de alguem com baixa quantia de ReviewTokens entrar pro comitê e dar aprovação final para algum artigo.

---

Estratégia:

A base do projeto web será feito em Django, para a fácil integração com Django-ninja já sendo utilizado. Para a parte gráfica será utilizado o framework Bootstrap, visando agilizar o desenvolvimento, que focará em um design simples e limpo para manter a seriedade do ambiente científico, mas com estética agradável para dar conforto ao usuário e proporcionar uma boa apresentação do projeto.

Os itens necessários serão:

• Verificar com os demais desenvolvedores possíveis requisitos de interface que eles possuirão no desenvolvimento do projeto.
• Montar o esqueleto de um conjunto de páginas contendo diferentes telas para cada ação de usuário.
• Implementar, conforme os requisitos levantados, o básico para possibilitar um ambiente de teste aos demais participantes do projeto.
• Criar um mecanismo de restrições de ações conforme características do usuário.
• Melhorar a UX do projeto conforme necessidade.
• Montar um design gráfico para o FrontEnd.

---

Requisitos

Verificar com os demais desenvolvedores os requisitos para as telas.
Conforme os demais realizarem progresso, monitorar possíveis alterações necessárias no front-end.

---

Cronograma

Aproveitando do planejamento dos demais participantes do projeto, logo no início realizar o levantamento dos requisitos de interface.
Após isso, Iniciar a confecção das telas a serem exibidas e aplicar as funcionalidades necessárias.
Conforme novos requisitos aparecem e novas restrições são identificadas, continuar atualizando o projeto para suportá-las.
Apenas na fase final, retrabalhar a interface para deixá-la com a aparência esperada, iniciando o processo após montar uma expectativa de tempo de realização para essa etapa, garantindo que ela estará pronta próximo do final do semestre, mas com tempo hábil para revisões.

Entrega da A2: Método de verificação de autoria

Introdução

O projeto visa criar um método de verificação de autoria para garantir a integridade dos dados do artigo como imagens e informações quanto ao autor utilizando-se das tecnologias possíveis através da Blockchain e DApps, combatendo falsificações e plágios.

Estratégia

• Estudar a literatura existente quanto a métodos de verificação de proveniência e autenticação de informações
• Criar um método para a comprovação de autoria
• Analisar a possibilidade da implementação do método na plataforma DAPH

Requisitos

• Informações quanto ao autor (Possivelmente Ethereum Wallet e ORCID ou similar)

Cronograma

• Entrega do Plano de Trabalho (02/12)
• Estudo da literatura existente (02/12 - 07/12)
• Desenvolvimento do método de comprovação (07/12 - 13/12)
• Análise quanto a integração na DAPH (13/12 - 15/12)
• Entrega do projeto (15/12)

Entrega da A1: Criar método para envio da revisão - Plataforma DAPH

Projeto: Criar método para envio da revisão - Plataforma DAPH

---

Curso de Criptomoedas e Blockchain
Aluno: Vanessa Berwanger Wille

Introdução

O objetivo desse trabalho é fundamentar a implementação de algum componente da plataforma Decentralized Autonomous Publishing House – DAPH, que propõe um mecanismo baseado em blockchain para descentralizar a publicação científica, descrito no artigo Decentralising scientific publishing.

Como exposto no artigo, uma vez que um revisor decide revisar um manuscrito, ele deve preparar o documento com seus comentários e enviá-lo ao InterPlanetary File System (IPFS), sendo que uma transação é feita para registrar a revisão e transmiti-la como disponível para avaliação. Esse ciclo pode se repetir várias vezes até ocorrer uma melhoria substancial do artigo em resposta às questões levantadas pela(s) revisão(ões), que serão classificadas por outros revisores, editores, autores e até leitores, procurando atingir uma classificação mínima (os primeiros revisores a entregar boas críticas, de acordo com a escala de classificação, serão pagos).

Assim sendo, para que a plataforma funcione devidamente, é necessário o desenvolvimento de método para envio das revisões, que será o propósito principal do projeto.

Estratégia:

Para criar esse método, a estratégia a ser seguida é:

• Entender melhor os smart contracts e a ferramenta Solidity.

• Modificar o contrato DPublish.sol (contrato para gerenciar o sistema, permitindo, por exemplo, um usuário submeter um artigo e outro usuário revisá-lo) a partir de template disponibilizado pelo projeto Open Zeppelin e realizar as alterações necessárias, criando função(ões) que permite(m) o envio da revisão e o recebimento do pagamento (ReviewToken).

• Preparar testes para verificar as funcionalidades.

• Desenvolver um front-end com as funcionalidades de download de arquivos (para o revisor poder baixar os arquivos) e upload de revisões (para o revisor enviar o documento com seus comentários).

Requisitos:

• Compreender o funcionamento dos contratos e, especialmente, do DPublish.sol.

• Implementação dos métodos de submissão de artigo no contrato DPublish.sol.

• Funcionalidades para que um revisor se inscreva como revisor e, caso ele não tenha uma carteira, seja criada uma.

Cronograma

Espero seguir a sequência dos tópicos especificada em “estratégia”, sendo que o tempo para cada tarefa dependerá das implementações de colegas e do meu entendimento a respeito dos assuntos.

Entrega A1: Processo de submissão de artigos (API, contrato solidity, front-end)

Introdução

Levando em conta os protótipos de implementação Dpublish (para os contratos) e DAPH_API (Frontend e Backend em Python), escolhi desenvolver o contrato de publicação e a API para submissão de manuscritos, bem como um front-end associado a essa tarefa.
O desenvolvimento dessa proposta envolve 4 atividades (em ordem de prioridade):

• Adaptação do contrato DPublish.
• Possíveis adaptações ao protótipo da API disponibilizada.
• Iteração contrato/API.
• Desenvolvimento de um frontend apropriado para submissão de artigos.

Estratégia

Para o desenvolvimento dessa proposta é necessário antes de tudo ter um contrato de publicação apropriado. No momento, o contrato conta com um mapping entre o id/local do manuscrito e endereço da carteira do autor, o que é esperado. Entretanto, como descrito no artigo na seção Manuscript submission é necessário também que uma vez que uma vez que o autor tenha submetido o seu trabalho, esse manuscrito entre no estado de preprint, desse modo, é necessário também que haja uma associação entre o id e o estado do manuscrito (aguardando revisão, revisão 1, ...), no contrato.
Outros atributos podem vir a ser necessários a medida que os outros processos forem sendo desenvolvidos.
Com relação a API algumas poucas mudanças pontuais ao protótipo parecem ser necessárias.
Com relação ao modelo associado, muito pouco parece precisar ser modificado, visto esse já conta com entidades de autor, manuscrito e artigo, bem como campos apropriados.
A API deverá iteragir (fazer chamadas de submissão, por exemplo) com o contrato de publicação, isso será feito utilizando a biblioteca web3.py.
Com relação ao front-end, ainda não decidi como irei desenvolver (usando frameworks, ou não).
A medida que possível serão criados testes para avaliar a corretude de cada sub-atividade.

Requisitos

Durante esse processo certamente haverá comunicação com pessoas que estejam desenvolvendo atividades relacionadas, como a revisão, por exemplo.
Em particular esse processo tem como requisitos os protótipos do contrato de publicação e da API já disponibilizada.

Além disso, acredito que alguns requisitos surgirão à medida em que essa task seja desenvolvida, podendo ser incorporados no meu trabalho.

Cronograma

A minha ideia é desenvolver as sub-atividades (descritas na introdução) que não possuam dependências em ordem, até que todas sejam feitas.

Entrega A1: Implementação do método de versionamento

Aluno: Vinicius Heder
Matrícula: 211708502

Introdução

O problema a ser resolvido é o de publicação de artigos científicos, passando por sua avaliação e revisão feitas em comunidade. O software a realizar isto opera de maneria descentralizada com incentivos a cada participante para que realizem os papéis necessários para o funcionamento do sistema. Uma das demanads é a de que uma vez que uma publicação é aprovada, seja possível fazer alterações nela, e é isto o que irei implementar

Estratégia

As alterações devem ser feitas pelo próprio autor, e a publicação não pode simplesmente ser atualizada, mas sim versionada: a nova versão ficará salva, assim como a(s) anterior(es), para que nenhuma informação seja perdida. Tal nova versão deve, então, ser validada tal qual uma nova publicação (a princípio, mas outros métodos podem ser avaliados). Isto será implementado após a implementação dos requisitos (abaixo), e a testagem será feita através da alteração de um dos artigos já publicados, lançando sua nova versão no sistema e checando se permanece consistente com as outras partes do sistema. Idealmente fazer estes versionamentos até uma versão 3 ou 4.

Requisitos

Sistema de publicação:
-Sistema de envio do artigo
-Sistema de avaliação do artigo e das reviews
-Sistema de publicação final, após aprovação do artigo

Cronograma

1-Estudar os sistemas citados em 'Requisitos' e entender seu funcionamento e integração
2-Implementar a interface (frontend) de alteração do artigo:
O dono do artigo pode escolher um artigo e fazer um upload de uma nova versão deste
O dono do artigo deve informar as diferenças e o motivo da alteração
A princípio o sistema não checaria o diff do artigo, mas poderia ser um passo extra
3-Fazer a interface (backend) com as outras partes do sistema:
A nova versão do artigo passa pelo processo de avaliação como um novo artigo sendo publicado
A única diferença é que a nova versão possuí algumas informações a mais, como versão anterior, nota desta versão...
4-Após a versão ser aprovada, fazer com que ela substitua a versão anterior onde ela é apresentada, e com que a versão anterior seja apresentada como versão antiga de artigo X versão N.
5-Executar testes para garantir que tudo é consistente para artigos com somente uma vesão, artigos com duas versões, e artigos com 3 ou mais versões

A duração de cada atividade não é sabida, dado que os requisitos são necessários para melhor análise
Fazendo uma estimativa, acredito que a destribuição de tempo para as atividades, na ordem apresentada, será em torno de 5%, 15%, 30%, 30%, 10%

Entrega da A1: Implementar método de avaliação de revisões.

Aluno: Bruno Pereira Fornaro

Matrícula: 211708042

Implementar método de avaliação de revisões.

Introdução

Neste projeto, anseia-se desenvolver um método para a avaliação das revisões feitas nos artigos submetidos na plataforma DAPH (Decentralized Autonomous Publishing House), considerando que isso é de suma importância para a validação dos artigos e do funcionamento da proposta de solução para a comunicação científica de maneira descentralizada. 

Essas avaliações são, resumidamente, "notas" que os usuários da plataforma vão poder atribuir às revisões feitas em cada artigo, de forma que seja feita uma classificação (e desclassificação) das revisões assim como dos revisores com base numa média ponderada dessas notas.

Nesse contexto, isso deve ser implementado na parte de software no back-end (a lógica que rege como as avaliações interagem com o sistema) e no front-end (a apresentação interativa para o usuário final) da plataforma para que a funcionalidade seja incorporada no resultado final para os usuários possam utilizar.

Especificações

Têm-se em vista que a avaliação das revisões deve ser de tal forma que não somente crie um ranking das avaliações em ordem de importância (ou qualidade de avaliação, a depender da interpretação) mas também possa "desclassificar" revisões tendenciosas (conluios, rivalidades e outras formas de viés que prejudiquem o método científico). Isto é, é importante se atentar que uma revisão mal avaliada possa, em certos casos, levá-la a não ser considerada para o aprimoramento e a aprovação do artigo, assim como também isso impacta na classificação de participação e importância dos próprios revisores (dado que a classificação desses membros é parte fundamental para a que eles alcancem o status de revisor - reviewers).

Dessa forma, é razoável que avaliação da revisão seja feita não apenas de forma binária, como "aprovado" e "não aprovado", ou "upvote" e "downvote", mas que possa ser atribuída uma "nota" numa escala (discreta, mas  que possa ser convertida em contínua) como um número inteiro (ou com uma casa decimal, possivelmente aceitando apenas 0 ou 5 - representando "meio ponto" na nota) no intervalo fechado de 0 (zero) a 10 (dez), de forma que seria possível calcular uma média ponderada das avaliações, com os pesos sendo as classificação de participação de cada usuário que avaliou.

Além disso, por fim, é razoável que uma avaliação no contexto científico venha acompanhada de justificativas e não apenas seja realizada de forma completamente arbitrária e não auditável. Nesse sentido, as avaliações devem vir acompanhadas de comentários (textuais) que descrevem o motivo da nota que foi atribuída, para que seja possível que outros usuários reportem uma avaliação tendenciosa (como descrito para o caso de revisões tendenciosas) e ela seja desconsiderada.  

Estratégia

O desenvolvimento deverá seguir o seguinte fluxo até atingir o resultado final do projeto:

• Desenvolver um campo (atributo, variável) de atribuição de nota e comentários nas revisões dos artigos;

• Desenvolver um campo para a classificação dos usuários com base nas avaliações de suas revisões;

• Estabelecer a ponderação da média das notas das avaliações das revisões e das classificações dos usuários de acordo com a classificação dos usuários.

• Estabelecer regras de classificação (revisão deve ser atendida pelo autor) e desclassificação (a revisão pode ser desconsiderada pelo autor) das revisões com base nas avaliações (critérios de avaliações e notas mínimas);

• Preparar a entrada (e a forma - tipo - de entrada) das notas da revisão dadas pelos usuários;

• Desenvolver o campo para reportar avaliações (que sejam enviesadas, tendenciosas, maliciosas, etc.) e as consequências disso (número de "reports" para considerar que uma avaliação deve ser removida e até mesmo consequências - penalidades - para os usuários que submeteram essas avaliações);

• Implementar a parte de front-end para que os usuários possam realizar as avaliações, realizar os reports e que seja possível ver a média das avaliações, assim como os usuários verem suas classificações no próprio perfil (conta de acesso).

Requisitos

• O sistema de revisão de artigos já deve ter sido criado para que possa ser feita a avaliação da revisão;

• As entidades de autor, revisor e etc. já devem existir para que seja possível atribuir a cada um desses usuários uma classificação (como uma nota) com base nas avaliações de suas respectivas revisões.

Cronograma

O projeto deve ser desenvolvido com a ordem cronológica seguindo a ordem dos tópicos descritos na seção de Estratégia, sendo que o tempo em cada etapa do processo irá refletir a dificuldade encontrada em cada uma delas respectivamente. 

Bibliografia

COELHO, Flávio Codeço; BRANDÃO, Adeilton. Decentralising scientific publishing: can the blockchain improve science communication?. Memórias do Instituto Oswaldo Cruz, [s. l.], 19 ago. 2019. Disponível em: https://www.scielo.br/j/mioc/a/pGbLcFHfhKGvXvTYPcGrfWw/?lang=en#. Acesso em: 24 set. 2022.

DISKIN, Shiri. Tips for revisions of a scientific journal article. Science Write Right, [s. l.], 5 maio 2016. Disponível em: https://www.sciencewriteright.com/single-post/2016/05/10/tips-for-revisions-of-a-scientific-journal-article. Acesso em: 24 set. 2022.

Mist application was ended and possible solution

When I was studying the lectures, I had the following problem with Mist: https://ethereum.stackexchange.com/questions/89587/ethereum-wallet-hangs-at-startup-403-ws-error

Since this application was ended in 2019, a good recommendation would be this tutorial: https://merehead.com/blog/how-to-create-private-ethereum-blockchain/

In particular, the command geth attach --datadir XXX to use the Geth JavaScript console.

Entrega da A1: Depósito de tokens para remuneração de revisores (Dpublish)

Plano de trabalho - Depósito de tokens para remuneração de revisores (Dpublish)

Introdução

Esse arquivo tem por objetivo documentar o plano de trabalho de desenvolvimento de método(s) para depósito de tokens para remuneração de revisores na plataforma Dpublish.

Estratégia

A lógica básica para o processo de revisão é: após sucessivos ciclos de sugestões (dadas pelo revisor) e correções dadas pelo autor, o artigo fica em um estágio intermediário, aguardando que a revisão feita seja classificada por um número mínimo de outros revisores, editores, autores e até leitores em geral (que possuam um papel mínimo no sistema que permita realizar essa revisão).
Se essa classificação for acima de um classificação mínima, então o revisor recebe sua remuneração através de tokens ERC-721. Esse token irá conter a classificação que a revisão feita recebeu.

Dessa forma, será implementado um método que deve:

• Identificar qual classificação uma determinada revisão recebeu;
• Identificar que essa classificação foi acima da classificação mínima. Se não, o método não retornará tokens.
• Depositar ao agente revisor tokens ERC-721, de forma proporcional a classificação recebida.

O método será implementado no contrato ReviewToken.sol.

Os testes unitários para esse contrato serão implementados em Javascript em um novo arquivo ReviewToken.test.js no pacote test.

Requisitos

Como requisitos, deveremos ter:

• Definição da classificação mínima para o artigo receber status de aprovado.
• Conhecimento acerca de contratos com padrões ERC-721.

Cronograma

• 25/09 - Entrega do plano de trabalho.
• (01/10 a 15/10) - Estudos acerca de contratos no padrão ERC-721.
• (15/10 a 29/10) - Implementação do método em ReviewToken.sol.
• (31/10 a 05/11) - Validação da lógica desenvolvidada e resolução de possíveis débitos com colegas e professor.
• (07/11 a 20/11) - Implementação dos testes unitários e possíveis outros testes funcionais ou end-to-end que possam existir, incluindo suas correções.
• (21/11 a 28/11) - A2: entrega do trabalho.

Implementar uma presença por aula

O aluno não deve ser capaz de assinar a presença mais do que uma vez por aula.
Para implementar isso há varias possibilidades:

• Exigir a confirmação do professor;
• permitir que o contrato saiba quantas aulas o curso tem e qual a periodicidade, e assim distribuir as presenças de acordo.
• permitir a criação de aulas on the fly pelo professor para a qual cada aluno só pode ter uma presença.
• outras idéias?

Projetos 2022

Lista de alunos /projetos

Template do plano de trabalho.

Entrega A1: Métodos de submissão de artigo no contrato Dpublish.sol

Plano de Trabalho

Introdução

Esse projeto tem como objetivo desenvolver método(s) que permitam a submissão de artigos no contrato Dpublish.sol da plataforma Dpublish, sistema de publicação de artigos distribuída baseada neste artigo.

Estratégia

O processo de submissão de artigos consiste em armazenar o documento e submeter o seu endereço ao contrato de submissão, mas deve ser sempre executado por um autor, que terá sua identificação baseada no endereço da carteira utilizada para realizar a transação. Após a submissão, o manuscrito entra no estado de preprint. Uma taxa de submissão deve ser fixada pelo comitê diretor para pagar o número mínimo de revisores independentes para cada artigo.

Para que um autor submeta um arquivo, ele precisa comprar tokens, que representam o custo de entrada. Ele também pode receber tokens de acordo com a avaliação de seus trabalhos revisados.

Assim, é necessário desenvolver um método que permita que:

• O autor submeta seu artigo para publicação, por meio do pagamento da taxa definida;
• O endereço de quem publicou seja armazenado;
• Os pagamentos/saldo sejam controlados (verificar se o saldo é suficiente, descontar taxa, atribuir novo valor, etc.)

Requisitos

• Definição da taxa mínima para publicar um artigo;
• Exigir qual tipo de usuário pode "chamar" determinadas funções, como as que manipulam pagamentos, por exemplo.

Cronograma

O tempo para cada tarefa pode variar de acordo com a dificuldade encontrada em cada uma das etapas, mas o projeto será desenvolvido de acordo com o seguinte planejamento:

• 25/09: Entrega do plano de trabalho
• 30/09 a 09/10: Estudo do contrato e planejamento da implementação
• 10/10 a 04/11: Implementação e desenvolvimento do método no contrato Dpublish.sol
• 05/11 a 20/11: Teste, correções e aperfeiçoamentos necessários
• 21/11 a 28/11: A2 - Entrega do projeto final

Contato

Oi Flávio, boa tarde!
Queria falar um pouco sobre o andamento da A2 com o senhor, mas passei na sua sala agora há pouco e não te encontrei. :(
O senhor voltaria pra FGV hoje depois do almoço? Ou seria melhor falar por e-mail?

Reviewer allocation in Decentralising scientific publishing

In the paper Decentralising scientific publishing: can the blockchain improve science communication?, I did not understand the "Reviewer Allocation" part.

The paper will be submitted to the network by the authors and the reviewers would search for these works and choose the right one to review, right? It seems a little inefficient since a reviewer would have to read several papers until finding a good one to analyze, wouldn't they? I'm not an expert on the topic, so I may be saying nonsense, but how would the reviewer know which work is interesting and good for reviewing? Should a recommendation algorithm be integrated?

I also did not understand the following sentence: " The first reviewers to turn in good reviews (according to the rating scale) will get paid." Suppose there is a good paper and several reviewers want to correct it. A lot of effort will be made, but only one will receive the price. I know this is good for some things, but it appears that science is losing time with that. It would be more reasonable (I guess) that an independent (random, possibly) editor had to send for a reviewer on the topic.

Thanks for the paper!

Entrega da A1: Implementar o método para determinar o poder de voto para o contrato DPubGovernor

Plano de Trabalho

Introdução

Plano de trabalho que será desenvolvido para a A2. Seguindo as espeficações do artigo mostrado em aula, desenvolver um método para determinar o poder de voto para o contrato DPubGovernor, na plataforma Dpublish.

Estratégia

Pretendo determinar o poder de voto dos membros do comitê de direção, que é formado por editores e revisores escolhidos aleatoriamente dentro de uma amostra. Para isso, devo compreender as atividades do comitê e a melhor forma de determinar os pesos dos votos. Dentre as atividades do comitê estão definir as regras de smart-contracts, definir a taxa de submissão e o número mínimo de revisores independentes, definir uma recompensa para atrair pesquisas de alto impacto e alterar o workflow de publicações, caso necessário.

Dado que os editores são, em essência, revisores com alta potuação (fruto de trabalhos anteriores e revisões bem avaliadas), é razoável concluir que eles devem ter maior poder de decisão no comitê. Contudo, é necessário que haja uma forma de evitar monopólios que atendam aos interesses de um grupo fechado, já que isso faria com que o sistema fosse rapidamente dominado e inutilizado. Portanto, caso a definição do poder de voto seja dada por algum tipo de status dos membros, tempo de participação e ou hierarquia, os mandatos do comitê devem ser aleatórios e com uma duração não muito prolongada e a identidade dos membros deve ser mantida privada. Isso ajudará a evitar o problema supracitado.

Assim, a fim de definir o poder de voto para o contrato DPubGovernor, irei:

• Definir um tipo de hierarquia entre os revisores e editores;
• Determinar um peso baseano no número de membros do comitê;
• Definir estratégias para evitar monopólio;

Requisitos

A fim de conseguir implementar esse método, devo:

• ser capaz de entender as atividades do comitê de direção, bem como sua definição;
• conhecer o contrato DPubGovernor;
• entendimento básico dos demais processos de publicação;

Isso ajudará a decidir a melhor forma determinar o poder de voto.

Cronograma

• Plano de Trabalho (25/09)
• Estudos aprofundados no contrato DPubGovernor (31/09 a 07/10)
• Desenvolvimento e possíveis aperfeiçoamentos do projeto (07/10 a 28/10)
• Validações e fase de destagem (28/10 a 04/11)
• Entrega do projeto final (21/11 a 28/11)

Entrega da A1: Método de Compra de DPubTokens

>> Ler Documento de Entrega Formatado

---

Ou alternativamente, aqui vai uma versão em markdown.

Projeto: Método de Compra de DPubTokens

Luís F. Laguardia - 24 de setembro de 2022

VISÃO GERAL

Nesse projeto, objetaremos desenvolver uma ferramenta que possibilite a compra de DPubTokens para o DAPH - Decentralized Autonomous Publishing House, uma iniciativa baseada em Ethereum que visa tornar a publicação de artigos científicos mais fácil e justa. Para tal, usufruiremos de tecnologias como Django (base do front e back-end já estruturada do DAPH) e Stripe, uma API de pagamentos online para Python bem estabelecida e capaz de atender à grande demanda de usuários que o DAPH almeja atingir.

ESTRATÉGIA

• Estudar a documentação da Stripe e focalizar nas ferramentas necessárias para a aplicação no DAPH.
• Criar um projeto modelo que integre as funcionalidades da Stripe ao Django e seja capaz de lidar com pagamentos e contabilizá-los.
• Construir um MVP (Minimum Viable Product) que demonstre as capacidades da API Stripe com foco nas aplicações para o DAPH.
• Fazer a integração completa da ferramenta no repositório oficial, possibilitando efetivamente a compra de DPubTokens.

REQUISITOS

• Até a criação do MVP: Definição precisa dos planos de aplicação de transação monetária no DAPH, para a melhor preparação da ferramenta para as aplicações particulares.
• Até a finalização do projeto: Implementação do front-end no Django-Ninja capaz de se comunicar com o código escrito.

CRONOGRAMA

Planejamos concluir o projeto seguindo as etapas descritas na seção estratégia, na ordem descrita.

ESPECIFICAÇÕES

Stripe é uma API que fornece a infraestrutura de pagamentos para internet utilizada por empresas de grande escalão como Google, Zoom, Squarespace e Shopify. Ela tem uma documentação extensa que facilita o aprendizado rápido e boa integração com Django. Além disso, ela é muito reconhecida pela comunidade, e portanto há bastante suporte externo para eventuais dúvidas (como no StackOverflow). O nosso objetivo é aproveitar as ferramentas que eles oferecem para implementar a funcionalidade de aquisição de DPubTokens através de uma transação monetária pelo aplicativo web do DAPH.

Os DPubTokens são a criptomoeda utilizada no DAPH para compensar revisores de artigos e para possibilitar a submissão de um artigo novo à revisão. Como a base da iniciativa se sustenta em uma demanda considerável por revisões de artigos, é necessário fornecer a pesquisadores dispostos a oportunidade de submeter seu trabalho sem a obrigatoriedade da revisão de artigos. Além disso, os n primeiros pesquisadores a publicarem na plataforma não terão DPubTokens suficientes para submeter uma publicação; logo, é necessária a opção de uma entrada de fundos externa para iniciar as atividades na plataforma. A compra de DPubTokens com moedas de câmbio trás duas vantagens cruciais: fornece uma alternativa mais rápida para a publicação de artigos e dá valor substancial à criptomeda do DAPH. Por isso, é de suma importância que implementemos essa funcionalidade ao projeto.

Esse objetivo final deve ser alcançado através da execução das etapas listadas na seção estratégia. Como o projeto almeja um resultado de largo escopo, é esperado que nem todos os objetivos sejam atingidos no decorrer do curso. Nesse caso, a conclusão total do projeto pode ser extendida para períodos extracurriculares após o fim das aulas, possivelmente contando com o apoio dos colegas que trabalharem com o mesmo tema e/ou temas relacionados na 2º avaliação.

Entrega da A1 - Desenvolvimento do PaperToken e do steering comitee

Plano de Trabalho – Desenvolvimento do PaperToken e do steering comitee

Aluno: Marcelo Amaral de Souza Filho
Matrícula: 211708022

Introdução

Para este projeto, tendo em vista o funcionamento pleno do sistema DAPH - Decentralized Autonomous Publishing House, propõe-se o desenvolvimento com mais enfoque da parte de PaperTokens, necessária para a certificação da publicação de artigos, e o do steering comitee, ou apenas comitê, para prover os benefícios de um grupo com a fiscalização mais especializada sem perder a descentralização do sistema.

Estratégia

• Estudo do modelo de contrato de token ERC 721 do OpenZeppelin, para definir e desenvolver as especificações que melhor atendam ao escopo do projeto, como a inclusão de informação nos metadados, sempre evitando uso excessivo de recursos como espaço de armazenamento, mas tendo em mente as possíveis consequências em termos de segurança e confiabilidade.

• Estudo dos diferentes tipos de atores no sistema para a implementação segura do sistema de comitê, que deve ser tanto eficaz quanto imprevisível, garantindo a consistência da aprovação de submissões de artigos e a impossibilidade de abuso do sistema por agentes mal-intencionados.

• Testes com as versões iniciais das funcionalidades implementadas para garantir o seu comportamento esperado e evitar refatoração excessiva do código.

Requisitos

• Um sistema minimamente funcional para permitir a atribuição de tokens e de funções a diferentes endereços e testar a viabilidade das funcionalidades descritas acima.

• Parâmetros e conceitos a serem discutidos e definidos, quão aleatórios serão os números que representam aspectos como integrantes do comitê e duração do mandato.

Cronograma

Começando pelo desenvolvimento e elaboração dos conceitos centrais daquilo que será implementado, tomar um tempo para entender e dominar pelo menos o básico da linguagem usada e construir a base das funcionalidades a partir do que for feito pelos outros membros do projeto. Próximo do terceiro quartil do prazo estipulado, começar o foco em revisão, aprimoramentos e testes em vez de novas funcionalidades.