Notes.txt

- We could use digital certificates and then distribute accordingly;
- Client app has a command line interface. The library hides the complexity of communicating with the blockchain;
- Implement round change in blockchain;
- Blockchain is array of strings;
- The library catches the request and triggers the consensus;
- Main challenge: what can go bad on every step of the process.
- The library will never attack the request. Behaves well; Blockchain can only have f byzantine processes. The network is unreliable. There are already abstractions implemented to fighht this. What should the link garantee? What at does it already garantee? What should we implement? UDP simulates fair loss;
- Think of how to maintain the blockchain consistent having in mind byzantine processes: We could have a process not the leader faking being the leader. Think about that. We need to consider that leaders can be byzantine. Thats why we use round changes.
Only the leader can trigger consensus. What if the leader is byzantine?
If the leader is byzantine, receives the request from the client and changes the value on purpose? How to solve this?
- Digital signature is way heavier than MACs. There are situations when we may not need all digital signatures granting properties.
- If we want to use symmetric keys, we should distribute them and not assume they are already distributed. Make key exchange first. It is expensive but if the blockchain runs infinitly, it will prevail over the overhead of exchanging the keys. But theory teacher said theres no need to use symetric encription and we could just use assymetric encription for everyting;
- Don't make tests for normal functioning of the system that was already provided and it works; 
- Do tests for byzantine cases: the blockchain have byzantine members. Include the maximum byzantine cases in tests. A client byzantine is few cases. The members of the blockchain being byzantine are much more cases to test. 
- Understand very well how the link layer is being used on the consensus service. How are messages created, etc.
- Understand very well the normal case and only then, go to round changes.
- Make specific tests for STEP_2.
- In the report, what can go wrong? thats the important part. What can go right is not so important. For example: we are using signatures here because its important to mantain integrity.
- Actually, we can just use digital signatures for everything, and not worry about performance issues.
- The client could contact a server node (random), and then, of its not the lider, it replies with the lider id.

- Digital signatures allow a third process to verify authenticity of a message sent from P1 to P2.


- Report dependability: Temos X garantia pq usamos y e z mecanismos: garantias que sao dadas pelas assumptions. Algumas sao dadas pelo paper, outras sao dadas pelo codigo base que nos foi dado. E outras garantias que sao dadas por aquilo que nos acrescentamos. Falar disto no report.
- Falar de assumptions.


- Start timer after consensus start even if its not the leader. This means that client needs to broadcast append request to all processes: or maybe just a byzantine quorum.

- Change leader per instance is still necessary because one byzantine leader could be censoring a specific client internally, and the other nodes wouldn't notice as long as there is requests being fullfield (decided instances).

- Client needs to check quorum of nodes response: some opers need f+1 others need other 2f+1.

- So fazer append do value no ledger quando o anterior for appended

- There is a byzantine behavior that could happen within transactions.

- conseguir construir estado apartir da blockchain
- garantir que um bloco n é modificado quando o consensus começa

- Find a good place in the consensus to check again if transaction is valid.

For stage 1:
    - Fix concurrency. If we don't have a correct leader, there could be concurrency issues;
    - Justify round change. Mandar mensagens piggybacked; Quando mandamos pre-prepeare, nao apanhei
    - Ter amplificação.

For stage 2:
    - Performance é muito importante: performace normal é performance assumindo que toda a gente sao amigos uns dos outros e ta tudo correto. Existe uma soluçao que melhora a performance no lado do server e piora no lado do cliente. Analisar esse impacto. Pode ser da outra way arround; Agr performance under atacks: atackes bizantinos. Garantir que os atackes nao sao problematicos e garantir que a performance nao piora. Alguns casos o IBF ja previne. Mas explicar esses casos que ja tao garantidos no report.
    - Garantir nao repudio: garatir mesmo depois das coisas ficarem na blockchain.
    - Garantir que conseguimos re-construir o estado a partir da blockchain. Ate mesmo os pagamentos ao produtor (tem de tar na blocchain).