Texto Castellano - Volumen 1 - Preleminar

Escaneo rapido de este libro preliminar.

 

Fischer vs Spassky

Game of Fischer Spassky

Robert James Fischer – Boris Spassky
Match por el Campeonato Mundial, partida 6
Reikiavik, 23-07-1972
Resultado: 1–0

Es la famosa partida en la que Fischer sorprendió con 1.c4, entrando posteriormente en el Gambito de Dama, y que Spassky llegó a aplaudir al finalizar. 

Partida 6 del match, ChessBase. 

Este tablero lo puedes ver en: https://devwebcl.blogspot.com/2024/04/beginning-c-7th-edition.html

Consuetudinaria

Del lat. consuetudinarius.

1. adj. Que es de costumbre.

   Sin.:

   • tradicional, acostumbrado, usual, habitual, ordinario.

   Ant.:

   • infrecuente, inusual, desacostumbrado.
2. adj. Habitual o reincidente.

   Ant.:

   • infrecuente, inusual, desacostumbrado.

    

   --> Comvencional ! 

 

Nefelibata

Nefelibata es un adjetivo que describe a una persona soñadora que camina o vive en las nubes, alejada de la realidad cotidiana.

 

PBFT, IBFT and QBFT Consensus Algorithms

The diagrams illustrate PBFT-family consensus algorithms (PBFT, IBFT, and QBFT), which are Byzantine Fault Tolerant protocols used in permissioned blockchains such as Hyperledger Besu.

---

1. PBFT (Practical Byzantine Fault Tolerance)

Purpose

• Allows distributed nodes to agree on a block even if some validators are malicious or faulty.
• Tolerates up to f Byzantine nodes among 3f + 1 validators.

Consensus Phases

1. Request

• A client sends a transaction to the leader (primary).

2. Pre-Prepare

• The leader proposes a new block.
• All validators receive the proposal.

3. Prepare

• Validators verify the proposed block.
• If valid, they broadcast a Prepare message.
• When a validator receives at least 2f + 1 Prepare messages, the block is considered prepared.

4. Commit

• Validators broadcast Commit messages.
• After receiving 2f + 1 Commit messages, the block is finalized.

5. Reply

• Validators execute the transactions.
• The client receives confirmation.

Characteristics

• Three communication rounds.
• Immediate finality (no forks).
• High message complexity (O(n²)).
• Excellent for permissioned networks.

---

2. IBFT (Istanbul Byzantine Fault Tolerance)

IBFT is an adaptation of PBFT designed specifically for Ethereum-compatible blockchains.

Consensus Flow

Leader Selection

• One validator becomes the proposer for the current round.

Proposal

• The proposer creates a candidate block.

Validation

Validators verify:

• Block format
• Signatures
• Transactions
• Gas limits
• Previous block hash

Prepare

• Validators multicast a Prepare message.

Commit

• After receiving 2f + 1 Prepare messages, validators send Commit.

Finalization

• Once 2f + 1 Commit messages are collected, the block is appended to the chain.

Additional Features

• Round-change protocol.
• Automatic leader replacement after timeouts.
• Better suited for blockchain environments than classical PBFT.
• Used in early versions of Hyperledger Besu and Quorum.

---

3. QBFT (Quorum Byzantine Fault Tolerance)

QBFT is the successor to IBFT and is currently the recommended consensus algorithm for Hyperledger Besu.

It keeps the PBFT consensus model while simplifying validator management and improving robustness.

Consensus Phases

1. Proposal

• The proposer creates a block.

2. Prepare

• Validators verify the proposal.
• Valid validators broadcast a Prepare message.

3. Commit

• After receiving 2f + 1 Prepare messages, validators broadcast Commit.

4. Finalization

• After 2f + 1 Commit messages, the block becomes final.

Improvements over IBFT

• More robust round-change mechanism.
• Better handling of validator changes.
• Simpler protocol specification.
• Improved interoperability with Enterprise Ethereum implementations.
• Lower operational complexity.

---

Comparison

Feature	PBFT	IBFT	QBFT
Byzantine Fault Tolerant	✅	✅	✅
Leader-based	✅	✅	✅
Consensus Phases	Pre-Prepare → Prepare → Commit	Proposal → Prepare → Commit	Proposal → Prepare → Commit
Immediate Finality	✅	✅	✅
Forks	No	No	No
Round Change	Basic	Improved	More Robust
Ethereum Compatible	No	Yes	Yes
Hyperledger Besu	No	Legacy	Recommended

---

Fault Tolerance

For all three protocols:

• Number of validators = 3f + 1
• Maximum Byzantine failures = f
• Quorum = 2f + 1

Examples

Validators	Byzantine Faults Tolerated	Quorum
4	1	3
7	2	5
10	3	7
13	4	9

---

Why QBFT is Preferred Today

For modern permissioned Ethereum networks (such as Hyperledger Besu), QBFT is generally preferred because it:

• Provides deterministic finality.
• Tolerates Byzantine failures.
• Includes a more reliable round-change mechanism.
• Simplifies validator management.
• Offers improved stability over IBFT while maintaining the same consensus guarantees.

This is why QBFT has become the default recommendation for new Hyperledger Besu deployments.

* IA English text generated
 

Mastering Ethereum: 2nd Edition

Mastering Ethereum, 2nd ed.

• Andreas M. Antonopoulos
• Gavin Wood
• Carlo Parisi
• Alessandro Mazza
• Niccolò Pozzolini

New edition of this classic book that has license:

https://github.com/ethereumbook/ethereumbook

This is the second edition of the book "Mastering Ethereum". You can access the book in the following ways:

• Buy the book on Amazon
• Read the online version

License

This work is licensed under Creative Commons. For the first 12 months after publication, it is available under the CC BY-NC-ND 4.0 license (Attribution-NonCommercial-NoDerivatives). After that period, it becomes available under the CC BY-SA 4.0 license (Attribution-ShareAlike).

 

Pro Git, 2nd ed.

This classic Git SCM book is open and released under a Creative Commons license.

It is essential reading for anyone who wants to gain a solid understanding of Git.

Anyone can also submit a pull request to fix issues or improve the content. I found only one issue several years ago and was able to submit a fix.

https://git-scm.com/book/en/v2

 

MATLAB Machine Learning Recipes

Technical reviewer: 

MATLAB Machine Learning Recipes - A Problem-Solution Approach
Dec 2026
Jan 2027

https://link.springer.com/book/9798868825149

 

Redis Lua Script

En Redis existe ZSET y script Lua para ejecucion de metodos/transacciones atomica.

1. un ZSET es más parecido a:

    Map<String, Long> + TreeMap<Long, Set<String>>

2. El script se ejecuta con Redis:

docker run -d \
  --name redis-poc \
  -p 6379:6379 \
  redis:7

3. El output esperado:

=== INITIAL BALANCES ===
ACCOUNT_A = 1000
ACCOUNT_B = 500

=== LUA RESULT ===
SUCCESS
1000
900
500
600

=== FINAL BALANCES ===
ACCOUNT_A = 900
ACCOUNT_B = 600

=== MODIFIED ACCOUNTS ===
ACCOUNT_A
ACCOUNT_B
 

 4. Codigo fuente:

Introducing ReScript 12

 Technical Reviewer

Introducing ReScript 12
Functional Programming for Web Applications
Nov 2026