(Traducción) Conceptos básicos de los documentos oficiales de Hyperledger (3) -Peers
Conceptos básicos de Fabric
Inicialmente, la aplicación seleccionará un conjunto de pares para generar propuestas de actualización del libro mayor. El par que se seleccionará se basa en la política de firma, que determina qué organizaciones deben firmar la propuesta de actualización antes de que se transmita la propuesta de actualización del libro mayor. Esto afecta la forma en que se entiende. Cualquier organización preocupada por si se reconoce una propuesta de actualización confirmará si la propuesta se reconoce antes de transmitirla a sus pares y ser aceptada por los pares.
La aprobación de una respuesta propuesta por parte de un par consiste en agregar su firma digital a la respuesta y firmar la respuesta completa con su clave privada. El contenido de la anotación se puede utilizar para demostrar que la respuesta fue generada por un par dentro de la organización. En nuestro ejemplo, si el par P1 pertenece a la Organización 1 (Org1), respaldar a E1 equivale a demostrar que la respuesta R1 en las transacciones T1 y L1 fue realizada por el par P65438+ de Org1.
La primera fase finaliza cuando la solicitud obtiene suficientes respuestas de propuestas firmadas.
Nos dimos cuenta de que los pares pueden devolver información diferente, por lo que la misma transacción puede tener información de devolución inconsistente. Esto puede deberse a que las respuestas se generan en diferentes momentos, para diferentes pares y en diferentes libros de contabilidad. En la mayoría de los casos, una aplicación puede solicitar una respuesta de sugerencia de actualización varias veces. Además, es más grave, pero la probabilidad es pequeña, porque la incertidumbre del código de la cadena conduce a respuestas inconsistentes. La incertidumbre es enemiga del código de cadena y los libros de contabilidad. Si esto sucede, es muy grave para la transacción propuesta y las respuestas inconsistentes a la propuesta ciertamente no se enviarán al libro mayor. Es imposible que un nodo independiente sepa que el resultado de la transacción es una transacción no determinista. Antes de detectar transacciones no deterministas, es necesario resumir y comparar las transacciones (estrictamente hablando, incluso si esto no es suficiente, posponemos esta discusión a la sección de transacciones, donde se analiza en detalle el no determinismo).
Al final de la primera fase, si la aplicación lo desea, puede descartar de forma segura las respuestas inconsistentes para finalizar la transacción antes de tiempo. Como veremos más adelante, si una solicitud envía una respuesta inconsistente al libro mayor, será rechazada.
Proceso 2 Embalaje
El segundo proceso de transacción es el embalaje. El nodo de orden es un punto clave en este proceso, ya que recibe respuestas de transacciones propuestas aprobadas de muchas aplicaciones. La parte ordenante clasifica las transacciones, empaqueta la gran cantidad de transacciones en bloques y prepara los bloques para distribuirlos a todos los pares conectados a la parte ordenante, incluidos los pares respaldantes.
La primera función del suscriptor es empaquetar recomendaciones de actualización de libros. En el ejemplo anterior, la aplicación A1 envía la transacción T1 respaldada por E1 y E2 al ordenante O1. Al mismo tiempo, la aplicación A2 envía la transacción T2 respaldada por E1 al ordenante O1. O1 empaqueta la transacción de A1, la transacción de A2 y otras transacciones en el bloque B2. Podemos ver que el orden de las transacciones en el bloque B2 es T1, T2, T3, T4, T6, T5, no necesariamente en el orden en que llegan al nodo de orden (este ejemplo muestra una configuración de orden muy simple).
El nodo suscriptor también recibirá sugerencias de actualización del libro mayor enviadas por diferentes aplicaciones en el canal de red. El nodo ordenador tiene la tarea de recopilar estas propuestas de actualización en un orden predefinido y empaquetarlas en fragmentos listos para la siguiente distribución. Estas piedras formarán una cadena de bloques. Una vez que el nodo del pedido genera un bloque con el tamaño esperado, o se excede el tiempo de espera máximo, el nodo del pedido enviará el bloque al par conectado a su canal específico. El tercer procedimiento detallará este proceso.
No existe una relación directa entre el orden de las transacciones en un bloque y el orden en que las transacciones llegan al nodo de orden. Las transacciones se pueden organizar en cualquier orden dentro de un bloque, y este orden es el orden en el que se ejecutan las transacciones. La cuestión es que existe una clasificación estricta de las transacciones, pero la clasificación no es importante.
El orden estricto de las transacciones en un bloque hace que Fabric sea diferente de la situación en la cadena pública donde las transacciones se pueden empaquetar en múltiples bloques diferentes. En Fabric, esta situación es imposible. El bloque generado por múltiples órdenes es el bloque final, porque después de que la transacción escribe el bloque, se determina el orden de posición de la transacción. Esto significa que la tela no se partirá. Una vez que una transacción se escribe en un bloque, no se puede reescribir más adelante.
Podemos ver que el par almacena libros y códigos de cadena, pero el ordenante no los almacena en absoluto. Cuando cada transacción llega a la orden, la orden simplemente empaqueta mecánicamente la transacción en bloques sin considerar el valor y el monto de la transacción. Esta es una característica importante del tejido. Todas las transacciones se ordenarán en estricto orden y no se descartará ninguna transacción.
Al final de la segunda fase, podemos entender que la responsabilidad del ordenante es recopilar propuestas de actualización de transacciones simples y necesarias, ordenarlas, empaquetarlas en bloques y prepararlas para su distribución.
Proceso 3 de Autenticación
El flujo de trabajo de la transacción final es la distribución y verificación de bloques del ordenante al par. Si la verificación tiene éxito, se enviará al libro mayor.
Específicamente, dentro de cada par, cada transacción en el bloque se verifica antes de actualizarse en el libro mayor para garantizar que todas las transacciones hayan sido aprobadas por la organización correspondiente. Las transacciones fallidas se retendrán para revisión futura y no se actualizarán en el libro mayor.
Además de la función de empaquetado en el proceso 2, el Ordenante también es responsable de distribuir bloques a los nodos pares en el proceso 3. En este ejemplo, O1 distribuye bloques a P1 y P2. P1 procesa el Bloque 2 y luego agrega el Bloque 2 al libro mayor L1 de P1. Mientras tanto, P2 procesa el bloque 2 y luego agrega el bloque 2 al libro mayor L1 de P2. Una vez que se completa la operación, el libro mayor L1 se actualiza en P1 y P2, y cada par puede enviar los resultados del procesamiento a las aplicaciones conectadas a ellos.
El ordenante distribuye bloques a los pares conectados a él, que es el comienzo del proceso 3. Los pares conectados al canal del nodo ordenante recibirán una copia de los nuevos bloques generados por el ordenante. Cada par procesará un bloque recibido de forma independiente, pero todos los pares procesan el bloque de la misma manera. De esta manera, los libros de contabilidad de diferentes pares pueden lograr * * conocimiento. No todos los pares tienen que estar conectados al nodo de ordenación; los fragmentos se pueden pasar entre pares a través del protocolo de chismes para que los pares también puedan procesar los mismos fragmentos de forma independiente.
Después de recibir el bloque, el par procesará las transacciones en el orden en que aparecen en el bloque. Para cada transacción, el par verificará si la organización relevante reconoce la transacción de acuerdo con la política de reconocimiento del código de cadena que generó la transacción. Por ejemplo, algunas transacciones pueden requerir el respaldo de una sola organización, mientras que otras transacciones requieren el respaldo de varias organizaciones simultáneamente. Este proceso de verificación verifica que los resultados o productos producidos por todas las organizaciones involucradas sean consistentes. Tenga en cuenta también que la tercera fase de verificación es diferente de la primera fase. En la primera fase, la aplicación solo recibe respuestas de los nodos respaldadores y determina si es necesario enviar una propuesta de transacción. Si una aplicación envía una transacción incorrecta y viola la política de aprobación, el par aún puede rechazar la transacción en la tercera fase de verificación.
Si el respaldo de la transacción es correcto, el par intentará enviar la transacción al libro mayor. Para escribir el libro de cuentas, el par debe verificar la coherencia del libro de cuentas para asegurarse de que el libro de cuentas actual sea coherente con el libro de cuentas actualizado. Este estado no siempre es consistente, incluso si la transacción cuenta con respaldos completos. Por ejemplo, es posible que otra transacción haya actualizado el mismo activo en el libro mayor, por lo que la transacción que estamos a punto de actualizar nunca se escribirá en el libro mayor. En este caso, el libro mayor de cada nodo debe mantenerse informado a través de la red y el método de verificación para cada nodo es el mismo.
El libro mayor se actualizará después de que el par verifique cada transacción independiente. Las transacciones fallidas se guardarán como material de revisión. Esto significa que el fragmento en el par es el mismo que el fragmento recibido de la parte ordenante, excepto por los indicadores en el fragmento que indican el éxito o el fracaso de la transacción.
También es importante tener en cuenta que el código de cadena no se ejecuta en la tercera fase, este paso solo se completará en la primera fase. Esto significa que el código de la cadena solo está disponible en el nodo que lo respalda y no en toda la red, lo que garantiza la seguridad y privacidad del código de la cadena en la institución que lo respalda. Esto es diferente a recibir los resultados de la ejecución del código de cadena. El resultado de la ejecución se compartirá con todos los pares del canal, independientemente de si puede firmar la transacción. El nodo de respaldo está diseñado de esta manera para facilitar la expansión.
Finalmente, cada vez que se envía un bloque al libro mayor del par, el par generará el evento correspondiente. Los eventos de bloque contienen todo el contenido de un bloque, mientras que los eventos de transacción de bloque contienen solo información breve, como si las transacciones en cada bloque son válidas. Los eventos de Chaincode generados por la ejecución de Chaincode también se pueden publicar en este momento. Las aplicaciones pueden registrarse para estos eventos y recibir notificaciones cuando ocurran. Estas notificaciones se completan en la tercera y última etapa del flujo de trabajo de la transacción.
En términos generales, podemos saber que los bloques generados por el ordenante en la tercera etapa se sincronizan continuamente con el libro mayor. El orden estricto de las transacciones en la cadena de bloques permite a cada par verificar consistentemente las transacciones en la red de la cadena de bloques y enviarlas al libro mayor.
Órdenes y **conocimiento
Todo el flujo de trabajo de la transacción se llama **conocimiento, porque todos los pares acuerdan el orden y el contenido de la transacción, que se realiza mediante la coordinación del nodo Ordenador. * * * El conocimiento es un proceso de varios pasos y las solicitudes solo serán notificadas cuando el proceso de conocimiento * * * finalice, pero el tiempo de notificación puede variar según los diferentes pares.
Hablaremos más sobre los ordenantes más adelante. Por ahora, solo pensamos en el ordenante como un proceso que recopila y distribuye propuestas de actualización del libro mayor desde las aplicaciones a los pares, quienes validan y actualizan el libro mayor.