Forem: Leonardo Machado

A study on the acceptance of code review

Leonardo Machado — Mon, 26 Aug 2024 13:19:52 +0000

Author: leomachadop | Affiliation: Mackenzie | Email: leomachadop@gmail.com | Date: 06/2016

Code review is the practice of a team member checking and reviewing code written by another member. Given this scenario, we can ask the following questions:

Do professionals enjoy performing reviews?
Do they believe this can make a difference in their work environment?
Do different segments in information technology influence how the review is conducted?
Does experience change how professionals conduct reviews?

Considering these questions, the aim of the work is to assess whether the practice of code review can aid in software development within companies, through a questionnaire developed and applied using statements found in the literature.

1. Introduction

Software development teams are constantly guided by various challenges in their daily routines. Complex tasks alone consume a lot of effort and, even so, after completion, they may result in failures or issues not found during development, even with unit tests. Regardless of the project, software quality must be valued at all times, from requirements gathering to system deployment.

According to CZERWONKA et al. (2015), there are several reasons why code review is used in the context of software engineering, among which stand out:

Finding defects;
Ensuring long-term maintenance of the code;
Knowledge dissemination tool;
Communicating continuous progress.

ANICHE (2013) states that code review has proven to be very effective in transferring knowledge to team members. When the reviewer examines the produced code, the person being reviewed explains the reasons for doing it that way and why certain tools were used, which greatly contributes to the professional and the team as a whole.

FAGAN (1976) proposed the idea of formal code review, also known as code inspection, which spread rapidly. In the proposed model, people have specific roles and should have the following functions:

Moderator: Considered the key person, not necessarily a technical expert or specialist in the software being inspected, helping to maintain the objectivity of the inspection. Should lead the team performing the inspection;
Designer: Responsible for designing the program;
Programmer: Responsible for translating the design into code;
Tester: Programmer responsible for performing test cases or other forms of testing the designer/coder's product.

In the model proposed by FAGAN (1976), at the end of the review, the moderator should produce a report with everything discussed and said during the inspection to ensure that all issues raised during the inspection are addressed in the rework.

FAGAN (1976) states that the ideal team for code review consists of 4 people, although this can vary depending on circumstances. If the code belongs to more than one programmer, the involved parties may conduct the code inspection. Inspections should be scheduled and managed with the same attention as other parts of the project, otherwise, they may be postponed or even avoided. The result in the short term has a negative effect, and repeated postponement may extend the overall schedule and increase project costs.

CZERWONKA (2015) states that inspections were conceived as formal meetings where participants prepare in advance. Unlike formal inspections, code review does not require participants to be in the same place or at a fixed time, facilitating reviews in geographically distributed teams.

According to BACCHELLI (2013), modern code review is a more informal process than proposed by FAGAN (1976) and can be done with the support of tools, personal meetings, and checking with the collaborator. COHEN et al. (2006) presents five ways to conduct code reviews:

Formal inspections: Model proposed by FAGAN (1976);
Over-the-shoulder: The author requesting the review shows the changes made to a team member, who examines and discusses what has been done. If the reviewer finds something wrong, pair programming can be done to find the best solution;
E-mail pass-around reviews: The author sends the code to people they want to review it. These examine the files, ask questions, and discuss with the author and others the necessary changes. This technique may generate high email exchange and difficulties in data collection;
Tool-Assisted reviews: Modern mechanism for performing code reviews with specialized tools that collect, transmit, and display files, comments, and defects, as well as collect metrics for greater visibility on the obtained numbers;
Pair Programming: In the agile methodology eXtreme Programming (XP), the code is produced by two people, who alternate activities as determined by the company or the pair. This verification process is important to avoid errors in development and is a form of code review.

COHEN et al. (2006) states that some groups of programmers do not use code review due to two reasons:

Ego;
The work of performing code review.

Regarding ego, COHEN et al. (2006) states that when someone is evaluating the code, the person being evaluated may see the process as constructive or a criticism. This can lead to two classes of programmers: collaborators who, when confronted with problems, will try to solve them and see code review as something beneficial to the project; and isolationists, who will continue to try to solve problems alone without seeking help. COHEN et al. (2006) also emphasizes that this is not exclusive to programmers and can occur on a larger scale among professionals.

1.1 Objectives

1.1.1 General Objective

The objective is to verify how IT professionals accept the code review process and evaluate how this process occurs.

1.1.2 Specific Objectives

The specific objectives of the project are as follows:

Verify if professionals conduct reviews, and if so, how they do it;
Verify if professionals believe this practice increases software quality;
Verify if professionals enjoy conducting reviews or if they oppose this practice;
Improve how reviews are conducted and how they can be better applied according to the company;
Verify how they feel when reviewing code and when being reviewed;
Evaluate how code review can assist in a software development project.

1.2 Research Problems

According to TERVONEN (1997), the difficulty in controlling the quality of the inspection lies in the fact that it is a mental task and cannot be directly observed. This means it is challenging to use control metrics to know if the inspector is truly focused and assess when the inspection process is complete.

Conducting research within corporate environments is extremely difficult, as companies treat their source code and information with confidentiality. Employees are often required to sign information security agreements that prevent them from discussing the project. For this work, it would be interesting to analyze developer commits and comments, in addition to applying the code validations done in ANICHE (2013) research. Therefore, the research will be conducted in the form of a questionnaire with complete confidentiality of personal data.

1.3 Justification

The research should be conducted so that IT companies, regardless of the software development process, analyze and verify the levels at which professionals can be better at reviewing code and being reviewed. Results on how professionals prefer the review to be conducted can also be obtained.

With the results obtained, companies can determine if the practice of code review is appropriate in their software development process and how it should occur. Among the benefits, we can mention and measure when the professional may feel uncomfortable with this practice, which can cause problems within the team. The research aims to assist companies regarding the team's well-being.

The major contribution the research can offer is to verify if professionals truly believe that software quality increases with this practice or if it may not help during development, depending on the level of qualification. We can assume that quality, as presented by ANICHE (2013) and BACCHELLI (2013), is indeed elevated, but this research aims to show if professionals believe this practice can be incorporated into their daily routine without causing problems within the team.

The work will provide solutions on how to conduct code review, what forms it can take, and what contributions can be obtained when adopted, analyzing the results of the field research to be conducted.

2. Literature Review

As mentioned by COHEN et al. (2006), code review can affect the personal side of programmers, as many do not feel comfortable when their code is reviewed. The author proposes that in scenarios with constant changes in requirements, agile methods are preferable to traditional ones, such as the Waterfall model. Additionally, COHEN et al. (2006) highlights that code review is an important way to maintain code quality and should be done before the code enters the client's environment, to minimize impacts. Direct benefits cited include:

Improvement of code quality;
Reduction of code defects;
Improvement in communication about code content;
Education of junior programmers.

Indirect benefits include:

Shorter development/test cycles;
Reduced impact on technical support;
Increased customer satisfaction;
More sustainable code.

COHEN et al. (2006) also presents the social effects of code review, pointing out two ways that can negatively affect the social environment of the development team:

Hurting feelings: Criticisms may be poorly received and provoke negative reactions, especially if the issue is complex;
"Big Brother" effect: When software monitors the developer's activities and automatically measures comments.

CZERWONKA (2015) states that code review:

Often does not find functionality issues that should block a code submission;
Should be performed by people with a specific set of skills;
The social aspect of code reviews cannot be ignored.

CZERWONKA (2015), based on data obtained from Microsoft, found that 15% of comments provided by reviewers indicate a possible defect, and less than 15% represent blocking defects. 50% of comments are general feedback on the code, and 33% are considered useful by the reviewed. The study also revealed that developers spend an average of six hours per week reviewing colleagues' code, which can be costly and complex. The author concludes that code review may not be performed efficiently, which is increasing costs. The research highlights that for Microsoft, code review is more effective in team training than in detecting software issues.

In the work conducted by ANICHE (2013), a comparison was made between two projects at Caelum to assess whether code review practice really helps in detecting issues. The research showed that, although defect numbers did not change significantly after review, knowledge dissemination and perceived quality improvement were notable. This study highlighted the importance of the human aspect in quality perception, even when metrics do not show a significant increase.

BACCHELLI (2013) discusses that in the 1970s and 1980s, code reviews were more formal and time-consuming. Currently, the process is lighter and less formal, with a greater focus on defect detection. Modern code review, with tools like CodeFlow, allows annotations directly on the code and interaction with the developer. The research indicated that developers expect to find defects, maintain team consistency, improve code quality, and evaluate design. The review is also seen as an opportunity for learning and knowledge transfer.

MANTYLA (2009) found that 75% of defects detected during code review do not visibly affect software functionality but are important for software evolution. Defects that prevent code evolution were also identified, being more valuable in long-lifecycle software.

BOEHM (2001) estimates that 60% of defects can be captured during code review and that identifying defects in the early stages of development is more cost-effective than finding them later. Factors influencing defect capture include review types, system size and complexity, and algorithm concurrency.

SIY (2001) proposes that 75% of defects found during code reviews are evolution problems affecting future development, rather than production errors.

According to TERVONEN (1997), inspections are used as software quality assurance techniques early in the software development process, i.e., well before coding. The development process follows this sequence:

Figure 1 Core of Software Production

TERVONEN (1997) describes the main inspection phases at the start of software development:

Initial Meeting: Inform expectations and distribute documents, assign roles, and train in inspection procedures;
Individual Inspection: Raise as many issues as possible and record improvements;
Editing: Evaluate and classify issues as defects or non-defects;
Follow-up: The inspection leader reviews and requests necessary changes.

KEMERER (2009) investigated the impact of design and code review on software quality and found that defects identified in the early stages are cheaper to fix. Inspection is considered the most effective technique, with rules such as:

Ideal number of inspectors: four;
Preparation rate: 100 lines per text/hour;
Evaluation rate: about 125 lines of code per hour;
Inspection meetings should not last more than two hours.

GILB (1994) suggests a preparation rate of 0.5 to 1.5 pages per hour and, for critical documents, 0.1 page per hour.

3. Summary of Research and Results

The goal of this research was to assess IT professionals' perceptions of code review and its impact on the work environment. For this, a questionnaire with 15 questions was developed and answered by 16 professionals from various IT sectors. The survey used Google Forms to facilitate data collection and analysis.

The results were presented in graphs and included information about participants' experience levels, types of code review they have used, and their perceptions of the benefits and challenges of this practice. Data revealed, for example, that most participants consider code review valuable for software quality and learning, and that review often helps avoid defects in production.

For complete details and the questionnaire, access the original work available on LinkedIn. For more information or clarifications, please get in touch.

4. Conclusion and Future Work

The results obtained from the questionnaire corroborate the research presented in the literature review, demonstrating the relevance of code review across various activity sectors of the interviewees. The analysis suggests that code review is an essential aspect that should be continuously evaluated and applied within companies.

The research involved 16 professionals, 12 (75%) of whom are experienced, with over five years of experience in IT, and 4 (25%) have less than five years of experience. This composition enriches the research, providing a balanced view by evaluating both experienced professionals and those with less time in the field.

Among code review practices, pair programming was the most cited, with 75% of respondents reporting that they have used it in their careers. This practice is widely known and adopted in IT companies. Next, the "over-the-shoulder" review practice was mentioned by 62.5% of participants, possibly due to its simplicity, as the reviewer is approached at the commit moment to review the code, without the need for a real-time process like in pair programming.

Regarding the values associated with code review, 93.8% of respondents highlighted the importance of increased quality, corroborating what the literature indicates. Increased learning was also mentioned, as the reviewer understands the technology to suggest improvements and, if not understood, learns from the reviewed.

As for daily challenges, 62.5% of respondents prefer to try to solve problems on their own before seeking help, while 37.5% seek help to resolve issues more quickly. Considering that 75% of respondents have over five years of experience, it can be concluded that most of these more experienced professionals tend to solve problems on their own.

When starting a new software project, 87.5% of respondents prefer code review over reading specification documents, indicating that code is seen as a more direct and practical way to understand the system and its business rules. Only 12.5% prefer formal documentation.

In the role of reviewer, 68.8% of respondents feel comfortable pointing out problems in the code, although 31.3% feel more at ease with close acquaintances or have difficulties communicating issues. This suggests that code review may be more effective when conducted in a comfortable and familiar environment. Alternatively, using emails for review might be a solution for cases where personal contact is not ideal.

As reviewed individuals, 68.8% are willing to learn from identified problems, and 31.3% depend on how the reviewer presents the issues. None of the respondents showed resistance to feedback or suggestions during the review, which is a positive sign for the acceptance of the review process.

When asked about recommending code review in a company that does not have it, 93.8% of respondents answered affirmatively, while 6.3% would not recommend it due to negative past experiences. This data indicates a strong acceptance of code review as a beneficial practice.

Regarding learning new techniques or technologies, 50% of respondents stated that learning occurs mainly when new technologies are used in projects, while familiarity with existing technologies leads only to improvements.

Regarding defect prevention in production, 93.8% of respondents believe that code review contributed to avoiding defects, while 6.3% said they take extra care during the commit. These numbers highlight the effectiveness of code review in preventing production issues.

Regarding motivation to conduct code reviews, 75% of respondents approach the process neutrally, merely fulfilling a requirement, while 25% show enthusiasm. This suggests that, although most recognize the importance of code review, it may be seen as a bureaucratic process by some.

Regarding automated code review tools, 75% of respondents do not use them, 18.8% use them, and 6.3% are unaware of these tools. The lack of tool usage may indicate an opportunity to optimize the code review process, reducing the time needed for preliminary analysis.

The analysis of the professionals' segments and their code review experiences reveals a variety of practices and opinions, helping to understand how review fits into different IT contexts. Participant comments highlight the usefulness of techniques like email for review, the importance of not drastically changing functionalities during review, and the relevance of review for learning and continuous improvement.

Future Work:

Future steps for this research include conducting practical tests beyond questionnaires, such as tracking code review progress empirically. It is important to maintain diversity among professionals involved and evaluate not only one project but several projects from different companies. This will allow a broader understanding of the practical effects of code review in different contexts and with a greater variety of technologies and development methodologies.

References

ANICHE, Maurício F.; SOKOL, Francisco Z. Efeitos da Prática de Revisão de Código na Caelum: Um Estudo Preliminar em Duas Equipes. 2014. Disponível em: http://www.aniche.com.br/wp-content/uploads/2013/04/wbma-final3.pdf. Acesso em: 23 jun. 2016.

BACCHELLI, Alberto; BIRD, Christian. Expectations, Outcomes, and Challenges of Modern Code Review. 2013. Acesso em: 20 jun. 2016. DOI: 978-1-4673-3076-3/13.

BOEHM, Barry; BASILI, Victor R. Top 10 List [Software Development]. 2001. Acesso em: jun. 2016. DOI: 10.1109/2.962984.

COHEN, Jason; BROWN, Eric; DURETTE, Brandon; TELEKI, Steven. Best Kept Secrets of Peer Code Review. Austin, TX: Smart Bear, 2006. Disponível em: http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf. Acesso em: 20 jun. 2016.

CZERWONKA, Jacek; GREILER, Michaela; TILFORD, Jack. Code Reviews Do Not Find Bugs: How the Current Code Review Best Practice Slows Us Down. 2015. Acesso em: 20 jun. 2016. DOI: 10.1109/ICSE.2015.131.

FAGAN, M. E. Design and Code Inspections to Reduce Errors in Program Development. Journal IBM Systems Journal, Riverton, NJ, USA, v. 38, n. 2-3, 1976. DOI: 10.1147/sj.382.0258.

FAN, C-F.; YIH, S. Prescriptive Metrics for Software Quality Assurance. 1994. Acesso em: jun. 2016. DOI: 10.1109/APSEC.1994.465237.

GILB, Tom; GRAHAM, Dorothy. Software Inspection. 1. ed. Wokingham, England: Addison-Wesley Professional, 1994.

KEMERER, Chris F.; PAULK, Mark C. The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data. 2009. Acesso em: jun. 2016. DOI: 0098-5589/09/$25.00.

MANTYLA, Mika V.; LASSENIUS, Casper. What Types of Defects Are Really Discovered in Code Reviews?. 2009. Acesso em: jun. 2016. DOI: 0098-5589/09/$25.00.

TELES, Vinícius Manhães. Programação em Par. 2006. Disponível em: http://www.desenvolvimentoagil.com.br/xp/praticas/programacao_par. Acesso em: 23 maio 2016.

TERVONEN, Ilkka; IISAKKA, Juha. Monitoring Software Inspections with Prescriptive Metrics. 1997. Department of Information Processing Science, University of Oulu, Oulu, Finland.

SIY, Harvey; VOTTA, Lawrence. Does The Modern Code Inspection Have Value?. 2001. Acesso em: 20 jun. 2016. DOI: 10.1109/ICSM.2001.972741.

Um estudo sobre aceitação da revisão de código

Leonardo Machado — Sun, 25 Aug 2024 20:50:20 +0000

Autor: leomachadop | Afiliação: Mackenzie | Email: leomachadop@gmail.com | Data: 06/2016

Revisão de código é o nome dado à prática de um membro da equipe verificar e revisar o código escrito por outro membro. Diante desse cenário, podemos fazer as seguintes perguntas:

Será que os profissionais gostam de realizar as revisões?
Eles acreditam que isso possa fazer diferença em seu ambiente de trabalho?
Segmentos diferentes na tecnologia da informação influenciam a forma como a revisão é realizada?
A experiência muda a forma como os profissionais realizam a revisão?

Considerando essas perguntas, o trabalho tem como objetivo avaliar se a prática da revisão de código pode ajudar no desenvolvimento de software dentro das empresas, por meio de um questionário elaborado e aplicado utilizando as afirmações encontradas na literatura.

1. Introdução

Equipes de desenvolvimento de software estão constantemente guiadas por diversos desafios em seu cotidiano. Tarefas complexas por si só consomem muito esforço e, mesmo assim, após a conclusão, podem resultar em falhas ou problemas que não são encontrados no momento do desenvolvimento, mesmo com testes unitários. Independentemente do projeto, a qualidade do software deve ser prezada a todo momento, desde o levantamento dos requisitos até a implantação do sistema.

De acordo com CZERWONKA et al. (2015), existem diversas razões para que a revisão de código seja utilizada no contexto de engenharia de software, dentre elas destacam-se:

Encontrar defeitos;
Garantir a manutenção do código a longo prazo;
Ferramenta de difusão de conhecimento;
Transmitir progresso contínuo.

ANICHE (2013) afirma que a revisão de código tem se mostrado muito eficiente quanto à passagem de conhecimento para os integrantes da equipe. Quando o revisor analisa o código produzido, quem está sendo revisado argumenta o motivo que o levou a fazer daquela forma e porque utilizou determinada ferramenta, o que contribui muito para o profissional e para o time como um todo.

FAGAN (1976) propôs a ideia da revisão de código formal, também chamada de inspeção de código, que se difundiu rapidamente. No modelo proposto, as pessoas possuem papéis específicos e devem possuir as seguintes funções:

Moderador: Considerada a pessoa chave, não necessariamente deveria ser técnico ou especialista no software que está sendo inspecionado, ajudando na objetividade da inspeção. Deve ter liderança sobre a equipe que está realizando a inspeção;
Designer: Responsável pela concepção do programa;
Programador: Responsável por traduzir o design em código;
Tester: Programador responsável por realizar os casos de testes ou outra forma de testar o produto do designer/codificador.

Dentro do modelo proposto por FAGAN (1976), ao final da revisão, o moderador deve produzir um relatório com tudo que foi discutido e falado na inspeção para garantir que todas as questões levantadas na inspeção sejam abordadas no retrabalho.

FAGAN (1976) afirma que a equipe ideal para revisão de código é composta por 4 pessoas, embora isso possa variar de acordo com as circunstâncias. Caso o código pertença a mais de um programador, os envolvidos podem realizar a inspeção de código. As inspeções devem ser agendadas e gerenciadas com a mesma atenção que outras partes do projeto, caso contrário, poderão ser adiadas ou até mesmo evitadas. O resultado disso a curto prazo tem efeito negativo, e o adiamento repetido pode alongar o cronograma geral e aumentar o custo do projeto.

CZERWONKA (2015) afirma que as inspeções foram concebidas como reuniões formais nas quais os participantes se preparam com antecedência. Ao contrário das inspeções formais, a revisão de código não exige que os participantes estejam no mesmo lugar nem em um horário fixo, facilitando a realização das revisões em equipes geograficamente distribuídas.

De acordo com BACCHELLI (2013), a revisão de código moderna é um processo mais informal do que o proposto por FAGAN (1976) e pode ser feita com o apoio de ferramentas, reuniões pessoais e verificação com o colaborador. COHEN et al. (2006) apresenta cinco formas de realizar a revisão de código:

Formal inspections: Modelo proposto por FAGAN (1976);
Over-the-shoulder: O autor que solicita a revisão mostra as alterações realizadas a um membro da equipe, que examina e discute o que foi feito. Se o revisor encontra algo errado, pode-se realizar a programação em pares para obter a melhor solução;
E-mail pass-around reviews: O autor envia o código para as pessoas que ele gostaria que realizassem a revisão. Estes examinam os arquivos, fazem perguntas e discutem com o autor e outros as mudanças necessárias. Esta técnica pode gerar alta troca de e-mails e dificuldades na coleta de dados;
Tool-Assisted reviews: Mecanismo moderno para realizar revisões de código com ferramentas especializadas que coletam, transmitem e exibem arquivos, comentários e defeitos, além de coletar métricas para maior visibilidade sobre os números obtidos;
Pair Programming: Na metodologia ágil eXtreme Programming (XP), o código é produzido por duas pessoas, que revezam as atividades conforme determinado pela empresa ou pela dupla. Esse processo de verificação é importante para evitar erros no desenvolvimento e é uma forma de revisão de código.

COHEN et al. (2006) afirma que alguns grupos de programadores não utilizam a revisão de código devido a dois motivos:

Ego;
O trabalho de realizar a revisão de código.

Quanto ao ego, COHEN et al. (2006) afirma que, quando alguém está avaliando o código, quem está sendo avaliado pode ver o processo como construtivo ou uma crítica. Isso pode levar a duas classes de programadores: colaboradores que, quando confrontados com problemas, tentarão resolvê-los e veem a revisão de código como algo benéfico para o projeto; e isolacionistas, que continuarão tentando resolver problemas sozinhos, sem pedir ajuda. COHEN et al. (2006) também enfatiza que isso não é exclusivo de programadores, podendo ocorrer em uma escala maior de profissionais.

1.1 Objetivos

1.1.1 Objetivo Geral

O objetivo é verificar como os profissionais de TI aceitam o processo de revisão de código e avaliar como este processo ocorre.

1.1.2 Objetivos Específicos

Os objetivos específicos do projeto são os seguintes:

Verificar se os profissionais realizam a revisão, e se sim, como realizam;
Verificar se os profissionais acreditam que esta prática aumenta a qualidade do software;
Verificar se os profissionais gostam de realizar a revisão ou se se opõem a esta prática;
Aprimorar a forma como a revisão é realizada e como ela pode ser melhor aplicada de acordo com a empresa;
Verificar como se sentem ao revisar o código e quando são revisados;
Avaliar como a revisão de código pode auxiliar em um projeto de desenvolvimento de software.

1.2 Problemas da Pesquisa

De acordo com TERVONEN (1997), a dificuldade em realizar o controle da qualidade da inspeção está no fato de que se trata de um trabalho mental e não pode ser diretamente observado. Isso significa que é difícil utilizar métricas de controle para saber se o inspetor está realmente concentrado e avaliar quando o processo de inspeção está completo.

A realização da pesquisa dentro de ambientes corporativos é extremamente difícil, pois as empresas tratam seu código fonte e suas informações com sigilo. Funcionários muitas vezes são obrigados a assinar termos de segurança da informação que os impedem de falar sobre o projeto. Para este trabalho, seria interessante analisar o commit e comentários dos desenvolvedores, além de aplicar as validações de código feitas na pesquisa de ANICHE (2013). Portanto, a pesquisa será feita na forma de questionário com total sigilo dos dados pessoais.

1.3 Justificativa

A pesquisa deve ser realizada para que empresas da área de TI, independentemente do processo de desenvolvimento de software, analisem e verifiquem os níveis em que os profissionais podem ser melhores para revisar o código e ser revisado. Também poderão ser obtidos resultados sobre como os profissionais preferem que a revisão seja realizada.

Com os resultados obtidos, as empresas poderão verificar se a prática da revisão de código é adequada em seu processo de desenvolvimento de software e a forma como deve ocorrer. Entre os benefícios, podemos citar e mensurar quando o profissional pode se sentir incomodado com esta prática, o que pode gerar problemas dentro do time. A pesquisa tem como objetivo auxiliar as empresas no que diz respeito ao bem-estar do time.

A grande contribuição que a pesquisa poderá oferecer é verificar se os profissionais realmente acreditam que a qualidade do software aumenta com esta prática, ou se ela pode não ajudar durante o desenvolvimento, de acordo com o nível de qualificação. Podemos partir do pressuposto que a qualidade, conforme apresentado por ANICHE (2013) e BACCHELLI (2013), realmente é elevada, porém esta pesquisa tem a intenção de mostrar se os profissionais acreditam que esta prática pode ser incorporada ao seu dia a dia sem gerar problemas no time.

O trabalho trará soluções sobre como realizar a revisão de código, quais as formas de realizá-la e quais contribuições podem ser obtidas quando adotada, analisando os resultados da pesquisa de campo que será realizada.

2. Revisão da Literatura

Conforme mencionado por COHEN et al. (2006), a revisão de código pode afetar o lado pessoal dos programadores, pois muitos não se sentem à vontade quando seu código é revisado. O autor propõe que, em cenários onde há mudanças constantes nos requisitos, os métodos ágeis são preferíveis aos tradicionais, como o modelo Cascata. Além disso, COHEN et al. (2006) destaca que a revisão de código é uma forma importante de manter a qualidade do código e que deve ser realizada antes que o código entre no ambiente do cliente, para minimizar impactos. Entre os benefícios diretos citados estão:

Melhoria da qualidade do código;
Redução de defeitos de código;
Melhoria da comunicação sobre o conteúdo do código;
Educação de programadores júnior.

Benefícios indiretos incluem:

Ciclos mais curtos de desenvolvimento/teste;
Impacto reduzido sobre o suporte técnico;
Maior satisfação do cliente;
Código mais sustentável.

COHEN et al. (2006) também apresenta os efeitos sociais da revisão de código, apontando duas formas que podem afetar negativamente o ambiente social da equipe de desenvolvimento:

Ferir os sentimentos: Críticas podem ser mal recebidas e provocar reações negativas, especialmente se o assunto for complexo;
Efeito "Big Brother": Quando softwares monitoram as atividades do desenvolvedor e medem automaticamente os comentários.

CZERWONKA (2015) afirma que a revisão de código:

Muitas vezes não encontra problemas de funcionalidade que devem bloquear uma submissão de código;
Deve ser realizada por pessoas com um conjunto específico de habilidades;
O aspecto social das revisões de código não pode ser ignorado.

CZERWONKA (2015), com base em dados obtidos na Microsoft, constatou que 15% dos comentários fornecidos pelos revisores indicam um possível defeito, e menos de 15% representam defeitos impeditivos. 50% dos comentários são feedbacks gerais sobre o código, e 33% são considerados úteis pelos revisados. O estudo também revelou que desenvolvedores gastam, em média, seis horas por semana revisando o código dos colegas, o que pode ser caro e complexo. O autor conclui que talvez a revisão de código não esteja sendo realizada de maneira eficiente, o que está aumentando os custos. A pesquisa destaca que a revisão de código, para a Microsoft, é mais eficaz no treinamento da equipe do que na detecção de problemas de software.

No trabalho realizado por ANICHE (2013), foi feito um comparativo entre dois projetos da empresa Caelum para avaliar se a prática da revisão de código realmente auxilia na detecção de problemas. A pesquisa mostrou que, embora os números de defeitos não tenham mudado significativamente após a revisão, a disseminação de conhecimento e a percepção de aumento de qualidade foram notáveis. Este estudo destacou a importância do aspecto humano na percepção da qualidade, mesmo quando as métricas não comprovam um aumento significativo.

BACCHELLI (2013) discute que, nas décadas de 70 e 80, as revisões de código eram mais formais e demoradas. Atualmente, o processo é mais leve e menos formal, com maior foco na detecção de defeitos. A revisão de código moderna, com o uso de ferramentas como CodeFlow, permite anotações diretamente no código e interação com o desenvolvedor. A pesquisa indicou que os desenvolvedores esperam encontrar defeitos, manter a consistência da equipe, melhorar a qualidade do código e avaliar o design. A revisão também é vista como uma oportunidade de aprendizagem e transferência de conhecimento.

MANTYLA (2009) encontrou que 75% dos defeitos detectados na revisão de código não afetam visivelmente a funcionalidade do software, mas são importantes para a evolução do software. Defeitos que impedem a evolução do código também foram identificados, sendo mais valiosos em softwares com ciclos de vida mais longos.

BOEHM (2001) estima que 60% dos defeitos podem ser capturados durante a revisão de código e que identificar defeitos nas fases iniciais do desenvolvimento é mais econômico do que encontrá-los mais tarde. Fatores que influenciam a captura de defeitos incluem os tipos de revisão, o tamanho e a complexidade do sistema e a concorrência nos algoritmos.

SIY (2001) propõe que 75% dos defeitos encontrados durante as revisões de código são problemas de evolução que afetam o desenvolvimento futuro, em vez de erros em produção.

De acordo com TERVONEN (1997) inspeções são utilizados como técnicas de garantia de qualidade do software no início do processo de desenvolvimento do software, ou seja, bem antes de codificá – lo. O processo de desenvolvimento segue o seguinte processo:

Figura 1 Core de produção de software

TERVONEN (1997) descreve as fases principais de inspeção no início do desenvolvimento de software:

Reunião inicial: Informar as expectativas e distribuir documentos, atribuir funções, e treinar em procedimentos de inspeção;
Inspeção individual: Levantar o maior número de questões possível e registrar melhorias;
Edição: Avaliar e classificar questões como defeitos ou não defeitos;
Follow-up: O líder de inspeção analisa e solicita as alterações necessárias.

KEMERER (2009) investigou o impacto do design e revisão de código na qualidade do software e encontrou que defeitos identificados em fases iniciais são mais baratos de reparar. A inspeção é considerada a técnica mais eficaz, com regras como:

Número ideal de inspetores: quatro;
Taxa de preparação: 100 linhas por texto/hora;
Taxa de avaliação: cerca de 125 linhas de código por hora;
Reuniões de inspeção não devem durar mais de duas horas.

GILB (1994) sugere uma taxa de preparação de 0,5 a 1,5 páginas por hora e, para documentos críticos, 0,1 página por hora.

3. Resumo da Pesquisa e Resultados

O objetivo desta pesquisa foi avaliar a percepção dos profissionais de TI sobre a revisão de código e seu impacto no ambiente de trabalho. Para isso, um questionário com 15 perguntas foi elaborado e respondido por 16 profissionais de diferentes setores de TI. A pesquisa utilizou o Google Forms para facilitar a coleta e análise dos dados.

Os resultados foram apresentados em gráficos e incluíram informações sobre o tempo de experiência dos participantes, tipos de revisão de código que utilizaram, e sua percepção sobre os benefícios e desafios dessa prática. Os dados revelaram, por exemplo, que a maioria dos participantes considera a revisão de código valiosa para a qualidade do software e o aprendizado, e que a revisão frequentemente ajuda a evitar defeitos em produção.

Para detalhes completos e o questionário, acesse o trabalho original disponível no LinkedIn. Para mais informações ou esclarecimentos, entre em contato.

4. Conclusão e Trabalhos Futuros

Os resultados obtidos no questionário corroboram as pesquisas apresentadas na revisão bibliográfica, demonstrando a relevância da revisão de código em diversos ramos de atividade dos entrevistados. A análise sugere que a revisão de código é um aspecto essencial que deve ser continuamente avaliado e aplicado nas empresas.

A pesquisa envolveu 16 profissionais, dos quais 12 (75%) são experientes, com mais de cinco anos de experiência em TI, e 4 (25%) possuem menos de cinco anos de experiência. Esta composição enriquece a pesquisa, proporcionando uma visão equilibrada, ao avaliar tanto profissionais experientes quanto aqueles com menor tempo de prática na área.

Entre as práticas de revisão de código, a programação em pares foi a mais citada, com 75% dos entrevistados relatando que a utilizaram em suas carreiras. Esta prática é amplamente conhecida e adotada em empresas de TI. Em seguida, a prática de revisão "sobre o ombro" foi mencionada por 62,5% dos participantes, possivelmente por ser mais simples, já que o revisor é acionado no momento do commit para revisar o código, sem a necessidade de um processo em tempo real como na programação em pares.

Em relação aos valores associados à revisão de código, 93,8% dos entrevistados destacaram a importância do aumento da qualidade, corroborando o que a literatura aponta. O aumento da aprendizagem também foi mencionado, uma vez que o revisor entende a tecnologia para sugerir melhorias e, caso não compreenda, aprende com o revisado.

Quanto aos desafios diários, 62,5% dos entrevistados preferem tentar resolver problemas sozinhos antes de buscar ajuda, enquanto 37,5% solicitam ajuda para resolver problemas mais rapidamente. Considerando que 75% dos entrevistados possuem mais de cinco anos de experiência, podemos concluir que a maioria desses profissionais mais experientes tende a resolver problemas por conta própria.

Ao iniciar um novo projeto de software, 87,5% dos entrevistados preferem a revisão de código a ler documentos de especificação, indicando que o código é visto como uma forma mais direta e prática de entender o sistema e suas regras de negócios. Apenas 12,5% preferem a documentação formal.

No papel de revisor, 68,8% dos entrevistados sentem-se confortáveis em apontar problemas no código, embora 31,3% se sintam mais à vontade com pessoas próximas ou tenham dificuldades em comunicar problemas. Essa questão sugere que a revisão de código pode ser mais eficaz quando realizada em um ambiente confortável e conhecido. Alternativamente, o uso de e-mails para revisão pode ser uma solução para casos onde o contato pessoal não é ideal.

Como revisados, 68,8% estão dispostos a aprender com os problemas encontrados, e 31,3% dependem da forma como o revisor expõe os problemas. Nenhum dos entrevistados demonstrou resistência às críticas ou sugestões durante a revisão, o que é um sinal positivo para a aceitação do processo de revisão.

Quando questionados sobre recomendar a revisão de código em uma empresa que não a possui, 93,8% dos entrevistados responderam afirmativamente, enquanto 6,3% não recomendariam devido a experiências passadas negativas. Este dado indica uma forte aceitação da revisão de código como uma prática benéfica.

Sobre o aprendizado de novas técnicas ou tecnologias, 50% dos entrevistados afirmaram que o aprendizado ocorre principalmente quando novas tecnologias são usadas em projetos, enquanto a familiaridade com tecnologias existentes leva apenas a aprimoramentos.

Referente à prevenção de defeitos em produção, 93,8% dos entrevistados acreditam que a revisão de código contribuiu para evitar defeitos, enquanto 6,3% afirmaram que tomam cuidado extra durante o commit. Esses números destacam a eficácia da revisão de código na prevenção de problemas em produção.

No que diz respeito à motivação para realizar revisões de código, 75% dos entrevistados abordam o processo de forma neutra, apenas cumprindo um requisito, enquanto 25% demonstram empolgação. Isso sugere que, embora a maioria reconheça a importância da revisão de código, ela pode ser vista como um processo burocrático por alguns.

Sobre ferramentas automatizadas de revisão de código, 75% dos entrevistados não as utilizam, 18,8% usam e 6,3% desconhecem essas ferramentas. A falta de uso de ferramentas pode indicar uma oportunidade para otimizar o processo de revisão de código, reduzindo o tempo necessário para a análise preliminar.

A análise dos segmentos dos profissionais e suas experiências de revisão de código revela a variedade de práticas e opiniões, o que ajuda a entender como a revisão se encaixa em diferentes contextos de TI. Comentários dos participantes destacam a utilidade de técnicas como o e-mail para revisão, a importância de não alterar funcionalidades drasticamente durante a revisão, e a relevância da revisão para a aprendizagem e melhoria contínua.

Trabalhos futuros:

Os próximos passos para esta pesquisa incluem realizar testes práticos além dos questionários, como acompanhar o andamento das revisões de código de forma empírica. É importante manter a diversidade dos profissionais envolvidos e avaliar não apenas um projeto, mas vários projetos de diferentes empresas. Isso permitirá uma compreensão mais ampla dos efeitos práticos da revisão de código em diferentes contextos e com uma variedade maior de tecnologias e metodologias de desenvolvimento.

Referências

BACCHELLI, Alberto; BIRD, Christian. Expectations, Outcomes, and Challenges of Modern Code Review. 2013. Acesso em: 20 jun. 2016. DOI: 978-1-4673-3076-3/13.

BOEHM, Barry; BASILI, Victor R. Top 10 List [Software Development]. 2001. Acesso em: jun. 2016. DOI: 10.1109/2.962984.

FAGAN, M. E. Design and Code Inspections to Reduce Errors in Program Development. Journal IBM Systems Journal, Riverton, NJ, USA, v. 38, n. 2-3, 1976. DOI: 10.1147/sj.382.0258.

FAN, C-F.; YIH, S. Prescriptive Metrics for Software Quality Assurance. 1994. Acesso em: jun. 2016. DOI: 10.1109/APSEC.1994.465237.

GILB, Tom; GRAHAM, Dorothy. Software Inspection. 1. ed. Wokingham, England: Addison-Wesley Professional, 1994.

KEMERER, Chris F.; PAULK, Mark C. The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data. 2009. Acesso em: jun. 2016. DOI: 0098-5589/09/$25.00.

MANTYLA, Mika V.; LASSENIUS, Casper. What Types of Defects Are Really Discovered in Code Reviews?. 2009. Acesso em: jun. 2016. DOI: 0098-5589/09/$25.00.

TELES, Vinícius Manhães. Programação em Par. 2006. Disponível em: http://www.desenvolvimentoagil.com.br/xp/praticas/programacao_par. Acesso em: 23 maio 2016.

TERVONEN, Ilkka; IISAKKA, Juha. Monitoring Software Inspections with Prescriptive Metrics. 1997. Department of Information Processing Science, University of Oulu, Oulu, Finland.

SIY, Harvey; VOTTA, Lawrence. Does The Modern Code Inspection Have Value?. 2001. Acesso em: 20 jun. 2016. DOI: 10.1109/ICSM.2001.972741.

A literature review on blockchain

Leonardo Machado — Sun, 25 Aug 2024 13:58:15 +0000

Author: leomachadop | Affiliation: PUC - RS | Email: leomachadop@gmail.com | Date: 28/08/2022

1. INTRODUCTION

We live in a contemporary era where changes occur in ways never before seen in human history. Innovations in various sectors of production and economy have undergone significant transformations, such as: how we consume music through streaming services, how we make payments via contactless transactions, how we connect with friends and family through social networks, among many other examples. These changes indicate that innovation will also occur in sectors with greater resistance to change, such as the financial market.

In this context, according to IANSITI and LAKHANI (2017), contracts, transactions, and their records are among the defining structures of economic systems with the aim of protecting assets and establishing organizational boundaries.

However, in an era where things tend to happen instantaneously, these tools create bureaucracies designed to manage them, often involving control by government or private institutions.

Blockchain promises to solve this problem with transparency, anonymity, and distribution, recording transactions between two parties in an efficient, verifiable, and permanent manner.

This paper aims to review the literature on blockchain and present the problems that this technology can help solve, thereby contributing to greater agility in the financial market.

2. THEORY

This section will be divided as follows, with the aim of presenting the relevant topics related to blockchain and the developments emerging from it:

Cryptocurrencies
Blockchain
Bitcoin
What is mining? Proof of work
List of coins
Exchange
Ethereum
Ethereum’s Merge
Smart contracts
NFT (Non-fungible Token)
DeFi - Decentralized Finance
Stablecoin
CBDC (Central Bank Digital Currencies)
Market potential
Challenges for blockchain and the FTX case
Brazilian players

2.1. Cryptocurrencies

As described by HOUBEN and SNYERS (2018), defining cryptocurrencies is not straightforward as it has become a “buzzword” referring to a wide range of technological developments related to cryptography, i.e., protecting information by transforming (encrypting) it into an unreadable format that can only be deciphered by those who possess the secret key.

2.2. Bitcoin

According to GHIMIRE and SELVARAJ (2018), Bitcoin was the first decentralized digital currency created by an individual under the pseudonym Satoshi Nakamoto, and was published in 2008 in the paper https://bitcoin.org/bitcoin.pdf. According to GHIMIRE and SELVARAJ (2018), Bitcoin has been growing across various business platforms as an alternative to fiat currencies (e.g., Brazilian real and US dollar), and some countries already recognize it as a payment method, where each user has an address that functions similarly to a traditional banking domicile.

2.3. Blockchain

According to Marco and Lakhani, blockchain is an open and distributed ledger that records transactions in a secure, permanent, and highly efficient manner. It was introduced in October 2008 as part of a proposal for Bitcoin, which is a virtual currency system that avoids a central authority from issuing currency and instead transfers ownership and confirms transactions through a process called mining. The first application of blockchain was Bitcoin.
The concept of a node, as described in ACADEMY (2021), is a physical or virtual connection point where all types of data and information can be created, sent, and received. In other words, they are the computers interconnected to the cryptocurrency network running the software that manages its entire operation.
GHIMIRE and SELVARAJ (2018) present the functioning of blockchain as shown in the figure below:

Figure 1: How blockchain works

New transactions are added to all nodes with the following steps:

Verify if transactions are valid
Each node groups new transactions into blocks
Each node works to discover the proof of work
When a node finds the proof of work, it is broadcast to all nodes
Nodes accept the block only if all transactions in it are valid
Nodes accept the block and work on creating the next block

2.4. What is mining? Proof of work

The mining process involves solving the proof of work, which will be described superficially without delving into the specific details of how it is done.
As presented by GHIMIRE and SELVARAJ (2018), the proof of work involves solving a complex encrypted mathematical puzzle, which requires a high level of computational cost for verification, and the computational power depends exclusively on miners.

2.5. Exchange

According to Lin (2019), exchanges are a tool for buying and selling an increasing percentage of cryptocurrencies and have the following benefits:

No need to trust a centralized exchange to protect and manage private keys
Potential for lower transaction fees The major exchanges can be viewed at https://coinmarketcap.com/pt-br/rankings/exchanges/

2.6. List of cryptocurrencies

The list of available cryptocurrencies can be accessed at: https://coinmarketcap.com/.

2.7. Ethereum

According to CHAUHAN (2018), Ethereum was proposed in 2013 and launched in 2015, and currently holds the second place in the cryptocurrency hierarchy. Ethereum is a public distributed blockchain, but the distinction is its potential compared to Bitcoin. While Bitcoin only offers cryptocurrency transfer, Ethereum allows for the execution of decentralized applications on the blockchain network known as smart contracts, using the programming language Solidity.
On the Ethereum network, when a node mines a block, it is rewarded with a cryptocurrency token called Ether, which in turn is used to deploy smart contracts and pay the fees associated with each transaction.

2.8. Ethereum’s Merge

MENDONCA (2022) presents the change made on September 15, 2022, to the Ethereum network, shifting from proof of work (PoW) to proof of stake (PoS). In proof of stake validation, the blockchain sends a block specifically to a validator. They have a period to check the transaction, sign it, and send it to other validators to agree with this validation, and everything is done automatically.

2.9. Smart contracts

A smart contract is a self-executing digital agreement that allows two or more parties to exchange money, property, shares, or anything of value, always in a transparent manner, avoiding conflicts and the need for third parties or regulatory authorities, such as central banks ZAPOTOCHNYI (2022).
A smart contract contains the same rules as a traditional contract, along with obligations, and verifies whether the conditions have been met. They are executed on a blockchain network, and when the interested parties agree to its terms, the program will execute automatically. Below are some examples of applications with smart contracts.

2.9.1. NFT (Non-fungible Token)

An exclusive digital identifier that cannot be copied, replaced, or subdivided, registered on a blockchain, and used to certify authenticity and ownership. According to Definition of NFT (2022), NFT ownership is recorded on the blockchain and can be transferred by the owner, allowing NFTs to be bought and sold. NFTs can be created by anyone and require little or no coding skills to create. According to EDUWAB (2022), the main uses of NFTs are: digital art, gaming, music, film. Smart contracts have enabled the creation of non-fungible tokens (NFTs) by allocating ownership and managing the transferability of NFTs.

2.9.2. Copyright management

Smart contracts can simplify and facilitate royalty payments DILMEGANI (2022).

2.9.3. Data markets

Platforms where users buy or sell different types of datasets and data streams from various sources, with companies like Datapace and Ocean Protocol using smart contracts to carry out operations DILMEGANI (2022).

2.9.4. Gaming

Smart contracts in games are used to allow players to perform common transactions, such as buying and selling items and specific game actions, such as waging wars for loot, character creation, etc.:

Axie Infinity: has various smart contracts used for different activities in the game, such as selling land, claiming, and creating rewards PEPI (2022)
RobotEra: allows players to create experiences within a Metaverse world. In the RobotEra Metaverse, players can interact with each other and play, fostering a strong community. Virtual lands, known as continents, and customizable robot companions take the form of NFTs, and players can customize the construction or personalize a continent/companion before selling it for profit PEPI (2022)

2.9.5. Healthcare

Patient records need to become automatically immutable and accessible only to specific researchers. Encrypgen

uses smart contracts to transfer patient DNA data to researchers for clinical trials DILMEGANI (2022).

2.9.6. Insurance

Smart contracts can improve insurance processes by automating claims management and data collection, for example:

In 2017, AXA launched a Fizzy insurance product that used smart contract technology to handle insurance claims for flight delays, and payment was triggered automatically if a delay exceeded two hours; however, it was discontinued in 2019 DILMEGANI (2022)
B3i provides insurance solutions on a blockchain platform, for example, providing smart contracts for reinsurers where contract terms can be parameterized DILMEGANI (2022)
Arbol provides weather and climate coverage with Ethereum-based smart contracts for agriculture, energy, maritime, and hospitality sectors. Smart contracts receive weather data almost in real-time and pay the correct party when the specified event occurs DILMEGANI (2022)

2.9.7. Logistics

Supply chain management manages the flow of goods and involves actively streamlining the supply-side activities of a company. When it reaches its destination, the ownership status of the item changes. Using smart contracts with the help of IoT sensors, if an item is lost during the process, its location can be detected. Routine tasks and payments can also be automated so that organizations do not need to communicate via documents DILMEGANI (2022)

Walmart was able to trace the source of products using smart contracts
HomeDepot improved its supplier management process by reducing the time to resolve discrepancies with them

2.9.8. International trade finance

We.trade offers smart contracts, eliminating credit risk by ensuring that when one party fulfills their obligations as outlined in the smart contract, payment is made automatically DILMEGANI (2022).

2.9.9. Real Estate

Smart contracts can accelerate the property transfer process. Property transfer contracts can be programmed and executed automatically. Propy facilitated the world’s first real estate transaction using smart contracts in 2017 DILMEGANI (2022)

Rental: properties can also be rented using smart contracts. Rent Peacefully allows for renting and listing properties on the blockchain
Real estate investment: smart contracts can be written for real estate transactions to provide rental income or dividends to holders

2.10. DeFi - Decentralized Finance

According to JENSEN and VON WACHTER (2021), decentralized financial applications (DeFi) represent a new generation of consumer-focused financial applications built as smart contracts deployed on blockchain technologies without the need for intermediaries.
Smart contracts have enabled sophisticated transactions such as loans, borrowing, and derivatives trading on DeFi platforms. Examples include:

AAVE: A DeFi platform that allows for lending and borrowing across various cryptocurrencies DILMEGANI (2022)
Opyn: A DeFi derivatives trading platform that uses smart contracts for options trading DILMEGANI (2022)

2.11. Stablecoin

As mentioned by MERCADOBITCOIN (2022), stablecoins are digital assets designed to maintain a 1:1 parity with fiat currencies issued by governments and central banks, and can be backed by various assets: gold, euros, oil, or even the S&P 500 index. Types of stablecoins include:

Fiat-backed: Pegged 1:1 with fiat money issued by central banks and governments
Commodity-backed: Based on physical commodities such as gold or oil
Crypto-backed: Backed by other cryptocurrencies
Algorithmic or non-collateralized: Fully backed by algorithms and smart contracts

2.11.1. Major Stablecoins

Tether: A digital currency created to mirror the value of the US dollar COINMARKETCAP (2022a)
USD Coin: A stablecoin pegged to the US dollar at a 1:1 ratio. Each unit in circulation is backed by $1 held in reserve, a mix of cash and short-term US Treasury securities COINMARKETCAP (2022b)
Binance USD: A stablecoin pegged 1:1 to the US dollar, issued by Binance COINMARKETCAP (2022c)
DAI: An Ethereum-based stablecoin, with issuance and development managed by the Maker Protocol and the MakerDAO decentralized autonomous organization COINMARKETCAP (2022d)

2.12. CBDC (Central Bank Digital Currencies)

According to MIKHALEV (2021), central bank digital currencies (CBDCs) represent a new form of electronic money, unlike cryptocurrencies such as Bitcoin or Ethereum, which are issued by central banks of specific countries as a digital version of banknotes. Countries where CBDCs have been launched include:

Bahamas: The Sand Dollar was issued by the Central Bank of the Bahamas in October 2020, becoming the world's first national CBDC SMITH (2022)
Nigeria: Became the first African country to launch a CBDC, the eNaira, stored in a digital wallet and used for contactless payments in-store and money transfers SMITH (2022)
Eastern Caribbean Currency Union: Created its own digital currency, DCash, aimed at speeding up transactions and reaching unbanked individuals SMITH (2022)

In Brazil, the Real Digital project is planned for launch in 2024.

2.13. Market Potential

According to a study by LTD (2022), the global blockchain market was valued at $4.67 billion in 2021, and it is projected to reach $163.83 billion by 2029, representing a compound annual growth rate of 56.3%.

2.14. Challenges for Blockchain and the FTX Case

MOVEMENT 2022 describes FTX as a cryptocurrency exchange with a market value of $32 billion that declared bankruptcy, being referred to as the "Lehman Brothers Moment" of cryptocurrencies (a reference to the 2008 financial crisis). Alameda Research, a hedge fund founded in late 2017, promised higher returns compared to traditional investments and used aggressive marketing to attract funds and clients.
On November 6, 2022, Binance announced it would sell approximately $530 million in FTT (FTX network token). However, FTX was unable to process the request, leading to a liquidity crisis due to insufficient funds and resulting in a withdrawal freeze. Binance attempted to acquire FTX but did not proceed due to concerns over irregularities, and FTX filed for bankruptcy on November 11, 2022. The aftermath of FTX's collapse continues to unfold, with many details still being investigated.
Following the FTX collapse and the ongoing uncertainties, various countries and governments are discussing and debating cryptocurrency regulation to prevent future collapses. KOLHATKAR 2022 states that investors are likely to become more cautious, and regulatory agencies overseeing digital assets are expected to be clearer and more stringent.

2.15. Brazilian Players

In Brazil, the following players provide access to some functionalities ESTADAO 2022:

NuBank: Offers Bitcoin and Ethereum to clients and is developing Nucoin
Mercado Pago: Launched Mercado Coin in August 2022, similar to a cashback program, where users earn part of their money back on MercadoLivre purchases, which can be used for future purchases or traded for other available cryptocurrencies
99pay: Allows Bitcoin purchases starting from R$1.00 and has also started offering Ethereum

3. CONCLUSION

As presented in this work, the primary motivation for creating blockchain was to aid in the de-bureaucratization of financial services, initially with Bitcoin and later with the help of the Ethereum community and smart contracts, which enable the creation, design, and maintenance of various business models.
It is important to highlight Ethereum's concern with environmental issues by shifting from proof of work to proof of stake and finally reaching a consensus after years of debate.
Exchanges have taken on a significant role in the cryptocurrency space, managing numerous wallets. However, using exchanges requires caution as they can access user wallets, which may lead to frauds such as the FTX case in late 2022.
Blockchain also plays a major role through CBDCs in assisting with the democratization of financial services globally. Financial inclusion tends to improve the conditions of people/countries/continents by providing greater opportunities for achieving necessary milestones. It is also interesting to note that some countries, through their central banks, are already implementing or testing concepts for these currencies, as seen with Brazil's Real Digital project.
The market potential for blockchain is substantial. The projected figures may be revised and updated, but based on the presented values, the market has significant potential. In Brazil, companies like MercadoPago, PicPay, and NuBank are already promoting blockchain technology, and this list is likely to grow in the coming years, although it depends on the macroeconomic scenario, global geopolitical stability, and pandemic control.

REFERENCES

ACADEMY, B. O que é um nó?, 2022. Disponível em: https://academy.bit2me.com/pt/que-es-un-nodo/.
CHAUHAN, A. et al. Blockchain and Scalability. 2018 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C), jul. 2018.
COINMARKETCAP, Binance USD (BUSD) Preço, Gráfico, Capitalização de Mercado, 2022d. Disponível em: https://coinmarketcap.com/pt-br/currencies/binance-usd/.
COINMARKETCAP, Dai (DAI) Preço, Gráfico, Capitalização de Mercado, 2022b. Disponível em: https://coinmarketcap.com/pt-br/currencies/multi-collateral-dai/.
COINMARKETCAP, Principais Tokens Stablecoin por Capitalização de Mercado, 2022a. Disponível em: https://coinmarketcap.com/pt-br/view/stablecoin/.
COINMARKETCAP, USD Coin (USDC) Preço, Gráfico, Capitalização de Mercado, 2022c. Disponível em: https://coinmarketcap.com/pt-br/currencies/usd-coin/.
Definition of NFT, 2022. Disponível em: https://www.merriam-webster.com/dictionary/NFT.
DILMEGANI, C. Top 9 Smart Contract Use Cases & Examples, 2022. Disponível em: https://research.aimultiple.com/smart-contracts-examples/.
EDUWAB, How to Create an NFT – Simply Explained, 2022. Disponível em: https://eduwab.com/how-to-create-an-nft-simply-explained/.
ESTADAO, Brasileiros passam a acessar mercado cripto via fintechs; entenda - Criptomoedas. Disponível em: https://einvestidor.estadao.com.br/ultimas/fintechs-passam-a-negociar-criptomoedas/.
GHIMIRE, S.; SELVARAJ, H. A Survey on Bitcoin Cryptocurrency and its Mining, 2018. Disponível em: https://ieeexplore.ieee.org/document/8638208.
HOUBEN, R.; SNYERS, A. Cryptocurrencies and blockchain Legal context and implications for financial crime, money laundering and tax evasion STUDY Requested by the TAX3 committee, 2017. [s.l: s.n.]. Disponível em: https://www.europarl.europa.eu/cmsdata/150761/TAX3%20Study%20on%20cryptocurrencies%20and%20blockchain.pdf.
IANSITI, M.; LAKHANI, K. The Truth About Blockchain, 2017. Disponível em: https://hbr.org/2017/01/the-truth-about-blockchain.
JENSEN, J. R.; VON WACHTER, V.; ROSS, O. An Introduction to Decentralized Finance (DeFi). Complex Systems Informatics and Modeling Quarterly, n. 26, p. 46–54, 30 abr. 2021.
KOLHATKAR S. Will the FTX Collapse Lead to Better Cryptocurrency Regulation? Disponível em: https://www.newyorker.com/business/currency/will-the-ftx-collapse-lead-to-better-cryptocurrency-regulation.
LIN, L. DECONSTRUCTING DECENTRALIZED EXCHANGES, 2019. [s.l: s.n.]. Disponível em: https://assets.pubpub.org/ob89i66u/61573938834913.pdf.
LTD, R. Blockchain Technology Market Size, Share & Trends Analysis Report by Type (Private Cloud, Public Cloud), by Application (Digital Identity, Payments), by Enterprise Size, by Component, by End Use, and Segment Forecasts, 2022-2030, 2021. Disponível em: https://www.researchandmarkets.com/reports/4582039/blockchain-technology-market-size-share-and.
MENDONCA, C. “The merge” da Ethereum: entenda o que é isso e os efeitos na cripto, 2022. Disponível em: https://blog.nubank.com.br/the-merge-ethereum-o-que-acontece-com-ether/.
MERCADOBITCOIN, O que é Stablecoin e qual a sua função, vale a pena?, 2022. Disponível em: https://blog.mercadobitcoin.com.br/o-que-e-stablecoin-e-qual-a-sua-funcao.
MIKHALEV, I. et al. CBDC Tracker, 2021. [s.l: s.n.]. Disponível em: https://cbdctracker.org/cbdc-tracker-whitepaper.pdf.
MOVEMENT, Q. AI-POWERING A P. W. What Happened To Crypto Giant FTX? A Detailed Summary Of What We Actually Know So Far. Disponível em: https://www.forbes.com/sites/qai/2022/12/13/what-happened-to-crypto-giant-ftx-a-detailed-summary-of-what-we-actually-know-here/?sh=2b6e4ca760fa.
PEPI, K. 10 Best NFT Games in 2022, 2022. Disponível em: https://cryptonews.com/news/best-nft-games.htm.
SMITH, I. CBDCs: These countries are using or launching digital currencies, 2022. Disponível em: https://www.euronews.com/next/2022/03/09/cbdcs-these-are-the-countries-are-using-launching-or-piloting-their-own-digital-currencies.
ZAPOTOCHNYI, A. What are Smart Contracts?, 2022. Disponível em: https://blockgeeks.com/guides/smart-contracts/#post-5615-_a8cy6rz9aai8.

Uma revisão bibliográfica sobre blockchain

Leonardo Machado — Wed, 14 Aug 2024 00:02:47 +0000

Autor: leomachadop | Afiliação: PUC - RS | Email: leomachadop@gmail.com | Data: 28/08/2022

1. INTRODUÇÃO

Vivemos numa era contemporânea onde as mudanças ocorrem de uma forma jamais vista na história da humidade, inovações em diversos setores da produção e economia sofreram grandes transformações, como por exemplo: a forma como consumimos músicas através de serviços de streaming, como efetuamos pagamentos através de pagamentos contactless, como nos relacionamos com nossos amigos e familiares através das redes sociais, dentre diversos outros exemplos, nos mostra que a inovação ocorrerá em setores com maior resistência a mudanças como o mercado financeiro.

Neste contexto conforme IANSITI e LAKHANI (2017) contratos, transações e seus registros estão entre as estruturas definidoras dos sistemas econômicos com o intuito de proteger ativos e estabelecer os limites organizacionais

No entanto numa era onde as coisas tendem a ocorrer de forma instantânea essas ferramentas geram burocracias formadas para gerenciá-las sempre com alguma das instituições governamentais ou privadas tendo o controle.

Blockchain promete resolver este problema, com transparência, anonimato e distribuída, registrando transações entre duas partes de forma eficiente, verificável e permanente.

Este trabalho tem como objetivo fazer uma revisão bibliográfica sobre blockchain e apresentar os problemas que essa tecnologia pode ajudar a solucionar para assim contribuir com maior agilidade no mercado financeiro.

2. TEORIA

A sessão será dividida da seguinte forma, com o intuito de apresentar os temas relevantes a blockchain e as derivações que estão surgindo a partir dele

Criptomoedas
Blockchain
Bitcoin
O que é minerar? Proof of work
Lista de moedas
Exchange
Ethereum
The Merge da Ethereum
Smart contracts
NFT (Token não fungível)
DeFi - Finanças descentralizadas
Stablecoin
CBDC (Central Bank Digital Currencies)
Potencial de mercado
Desafios para blockchain e o caso FTX
Players brasileiros

2.1. Criptomoedas

Conforme descrito por HOUBEN e SNYERS (2018), estabelecer uma definição de criptomoedas não é algo simples, por ter se tornado uma “palavra da moda” e se refere a uma ampla gama desenvolvimento tecnológicos a criptografia, ou seja, proteger a informação transformando-a (criptografando) em um formato ilegível sendo decifrado apenas por quem possua a chave secreta.

2.2. Bitcoin

Conforme publicado por GHIMIRE e SELVARAJ (2018) o Bitcoin foi a primeira moeda digital descentralizada digital ponto a ponto criada por um indivíduo sob o pseudônimo de Satoshi Nakamoto foi publicado em 2008 no paper https://bitcoin.org/bitcoin.pdf. Ainda de acordo GHIMIRE e SELVARAJ (2018) Bitcoin vem crescendo em várias plataformas de negócios como alternativa as moedas fiduciárias (real brasileiro e dólar americano, por exemplo) e alguns países já o reconhecem como método de pagamento, onde todo usuário contém um endereço que funciona como o domícilio bancário se comparado ao modelo tradicional.

2.3. Blockchain

De acordo com Marco e Lakhani blockchain é um livro contábil aberto e distribuído que registra transações de forma segura, permanente e muito eficiente. Foi introduzido em outubro de 2008 como parte de uma proposta do Bitcoin, que é um sistema de moeda virtual que evita uma autoridade central de emitir moeda e assim transferir propriedade e confirmar as transações pelo processo chamado de mineração. A primeira aplicação do blockchain foi o Bitcoin.
O conceito de nó conforme descrito em ACADEMY (2021) é um ponto de conexão físico ou virtual onde se pode criar, enviar e receber todos os tipos de dados e informações, ou seja, eles são os computadores que estão interligados a rede de criptomoeda executando o software que cuida de todo seu funcionamento.
GHIMIRE e SELVARAJ (2018), apresentam o funcionamento do blockchain e pode ser visto na figura abaixo:

Figura 1: Como funciona o blockchain

Novas transações são adicionadas para todos os nós com isso:

Verifica se as transações são validas
Cada nó agrupa novas transações em blocos
Cada nó trabalha para descobrir a prova de trabalho
Quando o nó encontra a prova de trabalho é transmitido para todos os nós
Os nós aceitam o bloco somente se todas as transações nele forem validas
Os nós aceitam o bloco e trabalham na criação do próximo bloco

2.4. O que é minerar? Proof of work

O processo de mineração consiste em resolver a prova de trabalho, aqui será descrito de uma maneira superficial sem entrar no detalhe de como é feita efetivamente.
Conforme apresentado por GHIMIRE e SELVARAJ (2018) a prova de trabalho consiste em resolver um complexo quebra-cabeça matemático criptografado, na qual exige um alto nível de custo computacional no processo de verificação e o poder computacional depende exclusivamente dos mineradores.

2.5. Exchange

De acordo com Lin (2019), as exchanges são uma ferramenta para comprar e vender uma porcentagem crescente de criptomoedas e possuem os seguintes benefícios:

Não há necessidade de confiar em uma Exchange centralizada para proteger e gerenciar as chaves privadas
Potencial para taxas de transações mais baixas As principais exchanges podem ser visualizadas em https://coinmarketcap.com/pt-br/rankings/exchanges/

2.6. Lista de criptomoedas

A lista com as criptomoedas disponíveis pode ser acessada em: https://coinmarketcap.com/.

2.7. Ethereum

De acordo com CHAUHAN (2018), ethereum foi proposto em 2013 e lançado em 2015 e no presente momento ocupa o segundo lugar na hierarquia de criptomoedas. Ethereum é um blockchain público distribuído, porém a distinção é o potencial que possuí se comparado ao Bitcoin, enquanto Bitcoin oferece apenas a transferência de criptomoedas, Ethereum permite a execução de aplicativos descentralizados na rede blockchain denominado: contratos inteligentes (smart contracts), com o uso da linguagem de programação Solidity.
Na rede do Ethereum quando um nó minera um bloco, é recompensado com um token de criptografia chamado Ether, que por sua vez é utilizada para implantar os contratos inteligentes e pagar as taxas associadas a cada transação.

2.8. The Merge da Ethereum

MENDONCA (2022) apresenta a mudança realizada em 15 de setembro de 2022 na rede Ethereum, alterando o proof to work (PoW) para proof of stake (PoS). Na validação de proof of stake, a blockchain envia um bloco especificamente para um validador. Ele terá um tempo para checar a transação, assinar e enviar para outros validadores concordarem com essa validação e tudo é feito de forma automática.

2.9. Contratos inteligentes (Smart contracts)

Um contrato inteligente é um acordo digital autoexecutável que permite duas ou mais partes trocarem dinheiro, propriedade, ações ou qualquer coisa de valor, de uma forma sempre transparente, sem conflitos evitando a necessidade de terceiros ou de alguma autoridade reguladora, como exemplo: banco central ZAPOTOCHNYI (2022).
O contrato inteligente contém as mesmas regras que um contrato tradicional, além das obrigações e verifica se as condições foram atendidas. São executados numa rede blockchain e quando as partes interessadas concordarem com seus termos o programa será executado automaticamente, a seguir serão apresentados alguns exemplos de aplicações com smart contracts.

2.9.1. NFT (Token não fungível)

Identificador digital exclusivo que não pode ser copiado, substituído ou subdividido, registrado em um blockchain e usado para certificar a autenticidade e a propriedade. Em Definition of NFT (2022) A propriedade de uma NFT é registrada no blockchain e pode ser transferida pelo proprietário, permitindo que NFTs sejam vendidas e negociadas. Os NFTs podem ser criados por qualquer pessoa e exigem pouca ou nenhuma habilidade de codificação para serem criados. De acordo com EDUWAB (2022) os principais uso de NFT são: Arte digital, jogos, música, filme. Os contratos inteligentes permitiram a criação de tokens não fungíveis (NFTs) alocando propriedade e gerenciando a transferibilidade de NFTs.

2.9.2. Gerenciamento de direitos autorais

Os contratos inteligentes podem simplificar e facilitar os pagamentos de royalties DILMEGANI (2022).

2.9.3. Mercados de dados

Plataforma na qual os usuários compram ou vendem diferentes tipos de conjuntos de dados e fluxos de dados de várias fontes, as empresas Datapace e Ocean Protocol utilizam smart contracts para realizar as operações DILMEGANI (2022).

2.9.4. Jogos

Contratos inteligentes em jogos são usados para permitir que os jogadores façam transações comuns, como comprar e vender itens e ações específicas do jogo, como travar guerras por saque, criação personagens etc.:

Axie Infinity: possuí diversos smartc contracts que são usados para diferentes atividades no jogo, como vender terras, reivindicar e criar recompensas PEPI (2022)
RobotEra: permite aos jogadores criar experiências dentro de um mundo Metaverse e dentro do metaverso RobotEra, os jogadores podem interagir uns com os outros e jogar, promovendo uma forte comunidade. Terrenos virtuais conhecidos como continentes quanto os companheiros robôs personalizáveis assumem a forma de NFTs e os jogadores podem personalizar a construção ou personalizar um continente/companheiro antes de vendê-lo para obter lucro PEPI (2022)

2.9.5. Assistência médica

Os dados arquivados dos pacientes precisam se tornar automaticamente imutáveis e acessíveis apenas a pesquisadores específicos. A Encrypgen usa contratos inteligentes para transferir dados de DNA de pacientes para pesquisadores para fins de testes clínicos DILMEGANI (2022)

2.9.6. Seguro

Os contratos inteligentes podem melhorar os processos de seguro automatizando o gerenciamento de sinistros e a coleta de dados, por exemplo:

Em 2017, a seguradora AXA lançou um produto de seguro Fizzy que usava a tecnologia de contrato inteligente para lidar com reclamações de seguro por atraso de voo e quando ocorria um atraso de mais de duas horas o pagamento era acionado automaticamente, porém em 2019 ele foi encerrado DILMEGANI (2022)
O B3i fornece soluções de seguros em uma plataforma blockchain, por exemplo, fornecem contratos inteligentes para resseguradoras onde os termos do contrato podem ser parametrizados DILMEGANI (2022)
A Arbol fornece cobertura meteorológica e climática com contratos inteligentes baseados em Ethereum para os setores de agricultura, energia, marítimo e hoteleiro. Os contratos inteligentes recebem os dados meteorológicos quase em tempo real e pagam a parte correta quando o evento especificado ocorre DILMEGANI (2022)

2.9.7. Logística

O gerenciamento da cadeia de suprimentos gerencia o fluxo de mercadorias e envolve a racionalização ativa das atividades do lado da oferta de uma empresa e quando chega no destino o status da propriedade do item muda. Usando contratos inteligentes com a ajuda de sensores IoT se um item porventura for perdido durante o processo, pode-se detectar sua localização. Também pode-se automatizar tarefas e pagamentos de rotina para que as organizações não precisem se comunicar por meio de documentos DILMEGANI (2022)

Walmart conseguiu rastrear a fonte dos produtos usando contratos inteligentes
HomeDepot melhorou seu processo de gerenciamento de fornecedores reduzindo o tempo na resolução de divergências com eles

2.9.8. Financiamento do comércio internacional

A we.trade, oferece contratos inteligentes, ela elimina o risco de crédito ao garantir que, quando uma das partes cumprir suas obrigações escritas no contrato inteligente, o pagamento seja feito automaticamente DILMEGANI (2022).

2.9.9. Imobiliária

Contratos inteligentes podem acelerar o processo de mudança de propriedade, contratos de mudança de propriedade podem ser programados e executados automaticamente, a empresa Propy permitiu a primeira transação imobiliária do mundo usando contratos inteligentes em 2017 DILMEGANI (2022)

Aluguel, as propriedades também podem ser alugadas usando contratos inteligentes a Rent Peacefully permite alugar e listar propriedades na blockchain
Investimento imobiliário, os contratos inteligentes podem ser escritos para transações imobiliárias, de modo que forneçam receita de aluguel ou dividendos aos detentores

2.10. DeFi - Finanças descentralizadas

Em JENSEN e VON WACHTER (2021) é citado que os aplicativos financeiros descentralizados (DeFi) são uma nova geração de aplicativos financeiros voltados para o consumidor compostos como contratos inteligentes, implantados em tecnologias blockchain sem a necessidade de intermediários.
Os contratos inteligentes permitiram transações sofisticadas, como empréstimos, empréstimos e transações de derivativos em plataformas DeFi, exemplos:

AAVE é uma plataforma DeFi que permite empréstimos e empréstimos em diferentes criptomoedas DILMEGANI (2022)
Opyn é uma plataforma de negociação de derivativos DeFi que utiliza contratos inteligentes para negociação de opções DILMEGANI (2022)

2.11. Stablecoin

Em MERCADOBITCOIN (2022) é mencionado que a stablecoin é um ativo digital que busca paridade de 1:1 com a moeda fiduciária, aquelas emitidas pelos governos e Bancos Centrais e a tecnologia pode ser utilizada para qualquer tipo de lastro: ouro, euro, petróleo, e até mesmo o índice S&P500. Os tipos de stablecoin que existem são:

Colateralizadas por moedas fiduciárias (Fiat-backed), pareadas na proporção 1:1 com o dinheiro emitido pelos Bancos Centrais e governos
Atreladas a commodities, baseadas em matérias-primas, como ouro físico ou barris de petróleo
Colateralizadas em criptomoedas, possuem lastro em outras criptomoedas
Algorítmicas ou não-colateralizadas, são totalmente lastreadas por algoritmos e pelos contratos inteligentes

2.11.1. Principais stablecoins

Tether Tether é uma moeda digital criada para espelhar o valor do dólar americano COINMARKETCAP (2022a)
USD Coin é uma stablecoin atrelada ao dólar americano na cotação de 1:1. Cada unidade desta criptomoeda em circulação é lastreada a US$1, mantida numa reserva, numa mistura de dinheiro e títulos do Tesouro Americano de curto prazo COINMARKETCAP (2022b)
Binance USD é uma stablecoin pareada 1:1 com o dólar americano, emitida pela Binance COINMARKETCAP (2022c)
DAI é uma stablecoin baseada no Ethereum, com sua emissão e desenvolvimento gerenciados pela Maker Protocol e pela organização autônoma descentralizada MakerDAO COINMARKETCAP (2022d)

2.12. CBDC (Central Bank Digital Currencies)

De acordo com MIKHALEV (2021) as moedas digitais do banco central (CBDC) representam uma nova forma de dinheiro eletrônico que, ao contrário das criptomoedas conhecidas, por exemplo Bitcoin ou Ethereum, é emitido por bancos centrais de determinados países, como uma versão digital das notas bancárias. Países onde os CBDCs foram lançados:

Bahamas: Sand Dollar foi emitido pelo Banco Central das Bahamas em outubro de 2020 se tornando o primeiro CBDC nacional do mundo SMITH (2022)
Nigéria: se tornou o primeiro país da África a lançar uma CBDC, o eNaira é armazenado em uma carteira digital e pode ser usado para pagamentos sem contato na loja, bem como para transferência de dinheiro SMITH (2022)
União Monetária do Caribe Oriental: criaram sua própria moeda digital DCash com o objetivo de ajudar a acelerar as transações e atender pessoas sem contas bancárias SMITH (2022)

No Brasil existe o projeto do Real Digital, e tem lançamento previsto para 2024.

2.13. Potencial de mercado

No estudo realizado por LTD (2022) foi calculado que o mercado global de blockchain foi avaliado em U$4,67 bilhões em 2021 e no ano de 2029 a projeção é que este valor seja de U$163,83 bilhões, ou uma taxa de crescimento anual composta de 56,3%.

2.14. Desafios para blockchain e o caso FTX

MOVEMENT 2022 descreve que a FTX é uma Exchange de criptomoedas tendo valor de mercado de U$32 bilhões para uma declaração de falência, onde muitos estão chamando de “Lehman Brothers Moment” (referência a crise financeira de 2008) de criptomoedas. No final de 2017 foi criado a Alameda Research (fundo hedge) com promessas de maiores ganhos se comparado aos investimentos tradicionais, utilizando de marketing agressivo para captar fundos e clientes.
No dia 06 de novembro de 2022, a Binance anunciou que venderia aproximadamente U$$ 530milhões em FTT (Token da rede FTX), no entanto a FTX não conseguiu processar a solicitação ocasionando numa crise de liquidez, pois eles não tinham fundos o suficiente o que levou a pausar as retiradas. A Binance tentou comprar eles, no entanto devido as suspeitas de irregularidades, eles não prosseguiram com a aquisição e no dia 11 de novembro de 2022 a FTX pediu falência. Até a presente data estão ocorrendo os desdobramentos e muitas informações estão sendo apuradas.
Após o colapso da FTX e os desdobramentos ainda desconhecidos que devem e vão ocorrer nos próximos meses/anos levaram diversos países e governos a discutir e debater sobre regulamentação de criptomoedas afim de evitar que um novo colapso ocorra, dessa forma KOLHATKAR 2022 afirma que os investidores tendam ser mais cautelosos e as agências governamentais que supervisionam os ativos digitais sejam mais claras e rigorosas.

2.15. Players brasileiros

No Brasil os seguintes players permitem acesso a algumas funcionalidades ESTADAO 2022:

NuBank, oferece Bitcoin e Ethereum aos clientes e está desenvolvendo a Nucoin
Mercado Pago, lançou a Mercado Coin em agosto de 2022 similar a um programa de cashback, onde os usuários quando compram no MercadoLivre recebem parte do dinheiro que pode ser usado em novas compras ou negociado em outras criptos disponíveis
99pay, oferece a possibilidade de comprar Bitcoin a partir de R$1,00 também passou a oferecer Ethereum

3. CONCLUSÃO

Conforme apresentado neste trabalho o maior motivador para criação de blockchain foi auxiliar na desburocratização dos serviços financeiros, num primeiro momento com o Bitcoin e posteriormente com o auxílio da comunidade Ethereum, com os contratos inteligentes que na prática permitem criar, idealizar e manter diversos modelos de negócios.
Importante ressaltar a preocupação da comunidade Ethereum com questões ambientais alterando a forma de mineração de proof of work para proof of stake além de terem finalmente entrado em um consenso que levava anos.
As exchanges tem ganhado assumido um papel grande se tratando de criptomoedas, uma vez que elas fazem a gestão de dezenas de carteiras mesmo que para utilizá-las não seja necessário ter conta em exchanges, e o uso delas exige um cuidado pois ela passa a ter o acesso a carteira dos usuários com isso pode ocorrer fraudes como o caso da FTX no final de 2022.
Blockchain também tem um papel grande por meio da CBDC no auxílio a democratização dos serviços financeiros mundialmente, e quando ocorre inclusão financeira a situação das pessoas/países/continentes tende a melhorar por prover uma perspectiva maior de conseguir as realizações necessárias, e também é muito interessante notar que conforme mencionado alguns países por meio de seus bancos centrais já estão implementando ou como no caso do Brasil estão fazendo provas de conceitos para a implantação dessas moedas.
O potencial de mercado para blockchain é grande, pode ser que o cálculo apresentado seja revisto e atualizado, mas tirando como parâmetro os valores apresentados, é um mercado que tem grande potencial e no caso do Brasil já vemos empresas auxiliando na divulgação como por exemplo: MercadoPago, PicPay e NuBank e essa lista só tende a aumentar com o passar dos anos, embora como tudo dependa de cenário macroeconômico, estabilidade geopolítica mundial e controle de pandemias.

REFERÊNCIAS PARA CONSULTA

ACADEMY, B. O que é um nó?, 2022. Disponível em: https://academy.bit2me.com/pt/que-es-un-nodo/.
CHAUHAN, A. et al. Blockchain and Scalability. 2018 IEEE International Conference on Software Quality, Reliability and Security Companion (QRS-C), jul. 2018.
COINMARKETCAP, Binance USD (BUSD) Preço, Gráfico, Capitalização de Mercado, 2022d. Disponível em: https://coinmarketcap.com/pt-br/currencies/binance-usd/.
COINMARKETCAP, Dai (DAI) Preço, Gráfico, Capitalização de Mercado, 2022b. Disponível em: https://coinmarketcap.com/pt-br/currencies/multi-collateral-dai/.
COINMARKETCAP, Principais Tokens Stablecoin por Capitalização de Mercado, 2022a. Disponível em: https://coinmarketcap.com/pt-br/view/stablecoin/.
COINMARKETCAP, USD Coin (USDC) Preço, Gráfico, Capitalização de Mercado, 2022c. Disponível em: https://coinmarketcap.com/pt-br/currencies/usd-coin/.
Definition of NFT, 2022. Disponível em: https://www.merriam-webster.com/dictionary/NFT.
DILMEGANI, C. Top 9 Smart Contract Use Cases & Examples, 2022. Disponível em: https://research.aimultiple.com/smart-contracts-examples/.
EDUWAB, How to Create an NFT – Simply Explained, 2022. Disponível em: https://eduwab.com/how-to-create-an-nft-simply-explained/.
ESTADAO, Brasileiros passam a acessar mercado cripto via fintechs; entenda - Criptomoedas. Disponível em: https://einvestidor.estadao.com.br/ultimas/fintechs-passam-a-negociar-criptomoedas/.
GHIMIRE, S.; SELVARAJ, H. A Survey on Bitcoin Cryptocurrency and its Mining, 2018. Disponível em: https://ieeexplore.ieee.org/document/8638208.
HOUBEN, R.; SNYERS, A. Cryptocurrencies and blockchain Legal context and implications for financial crime, money laundering and tax evasion STUDY Requested by the TAX3 committee, 2017. [s.l: s.n.]. Disponível em: https://www.europarl.europa.eu/cmsdata/150761/TAX3%20Study%20on%20cryptocurrencies%20and%20blockchain.pdf.
IANSITI, M.; LAKHANI, K. The Truth About Blockchain, 2017. Disponível em: https://hbr.org/2017/01/the-truth-about-blockchain.
JENSEN, J. R.; VON WACHTER, V.; ROSS, O. An Introduction to Decentralized Finance (DeFi). Complex Systems Informatics and Modeling Quarterly, n. 26, p. 46–54, 30 abr. 2021.
KOLHATKAR S. Will the FTX Collapse Lead to Better Cryptocurrency Regulation? Disponível em: https://www.newyorker.com/business/currency/will-the-ftx-collapse-lead-to-better-cryptocurrency-regulation.
LIN, L. DECONSTRUCTING DECENTRALIZED EXCHANGES, 2019. [s.l: s.n.]. Disponível em: https://assets.pubpub.org/ob89i66u/61573938834913.pdf.
LTD, R. Blockchain Technology Market Size, Share & Trends Analysis Report by Type (Private Cloud, Public Cloud), by Application (Digital Identity, Payments), by Enterprise Size, by Component, by End Use, and Segment Forecasts, 2022-2030, 2021. Disponível em: https://www.researchandmarkets.com/reports/4582039/blockchain-technology-market-size-share-and.
MENDONCA, C. “The merge” da Ethereum: entenda o que é isso e os efeitos na cripto, 2022. Disponível em: https://blog.nubank.com.br/the-merge-ethereum-o-que-acontece-com-ether/.
MERCADOBITCOIN, O que é Stablecoin e qual a sua função, vale a pena?, 2022. Disponível em: https://blog.mercadobitcoin.com.br/o-que-e-stablecoin-e-qual-a-sua-funcao.
MIKHALEV, I. et al. CBDC Tracker, 2021. [s.l: s.n.]. Disponível em: https://cbdctracker.org/cbdc-tracker-whitepaper.pdf.
MOVEMENT, Q. AI-POWERING A P. W. What Happened To Crypto Giant FTX? A Detailed Summary Of What We Actually Know So Far. Disponível em: https://www.forbes.com/sites/qai/2022/12/13/what-happened-to-crypto-giant-ftx-a-detailed-summary-of-what-we-actually-know-here/?sh=2b6e4ca760fa.
PEPI, K. 10 Best NFT Games in 2022, 2022. Disponível em: https://cryptonews.com/news/best-nft-games.htm.
SMITH, I. CBDCs: These countries are using or launching digital currencies, 2022. Disponível em: https://www.euronews.com/next/2022/03/09/cbdcs-these-are-the-countries-are-using-launching-or-piloting-their-own-digital-currencies.
ZAPOTOCHNYI, A. What are Smart Contracts?, 2022. Disponível em: https://blockgeeks.com/guides/smart-contracts/#post-5615-_a8cy6rz9aai8.