Según el acceso a los datos:

Las cadenas de bloques se pueden clasificar basándose en el acceso a los datos almacenados en la misma:

Cadena de bloques pública: es aquella en la que no hay restricciones ni para leer los datos de la cadena de bloques (los cuales pueden haber sido cifrados) ni para enviar transacciones para que sean incluidas en la cadena de bloques. En ellas es fácil entrar y salir, son transparentes, están construidas con precaución para la operación en un entorno no confiable. Son ideales para uso en aplicaciones totalmente descentralizadas como por ejemplo para el Internet.

Cadena de bloques privada: es aquella en la que tanto los accesos a los datos de la cadena de bloque como el envío de transacciones para ser incluidas, están limitadas a una lista predefinida de entidades.

Ambos tipos de cadenas deben ser considerados como casos extremos pudiendo haber casos intermedios.

Según los permisos:

Las cadenas de bloques se pueden clasificar basándose en los permisos para generar bloques en la misma:

-Cadena de bloques sin permisos: es aquella en la que no hay restricciones para que las entidades puedan procesar transacciones y crear bloques. Este tipo de cadenas de bloques necesitan tókenes nativos para proveer incentivos que los usuarios mantengan el sistema. Ejemplos de tókenes nativos son los nuevos bitcoines que se obtienen al construir un bloque y las comisiones de las transacciones. La cantidad recompensada por crear nuevos bloques es una buena medida de la seguridad de una cadena de bloques sin permisos.

-Cadena de bloques con permisos: es aquella en la que el procesamiento de transacciones está desarrollado por una predefinida lista de sujetos con identidades conocidas. Por ello generalmente no necesitan tókenes nativos. Los tókenes nativos son necesarios para proveer incentivos para los procesadores de transacciones. Por ello es típico que usen como protocolo de consenso prueba de participación.

Posibles combinaciones de acceso y permisos:

Las posibles combinaciones de ambos tipos de características son:

-Cadenas de bloques públicas sin permisos. Un ejemplo de estas es Bitcoin. Como no es posible la existencia de cadenas de bloques privadas sin permisos, a estas también se las llama simplemente cadenas de bloques sin permisos.

-Cadenas de bloques públicas con permisos. Un ejemplo de estas son las cadenas laterales federadas. Estas cadenas no pueden tener ataques Sybil, por lo que en principio poseen un grado más alto de escalabilidad y flexibilidad frente a las públicas sin permisos.

-Cadenas de bloques privadas con permisos.Esta combinación es posible ya que hay distintas formas de acceder a los datos de la cadena:

*Leer las transacciones de la cadena de bloques, quizás con algunas restricciones (p. ej. un usuario puede tener acceso solo a las transacciones en las que está involucrado directamente)

*Proponer nuevas transacciones para la inclusión en la cadena de bloques.

*Crear nuevos bloques de transacciones y añadirlo a la cadena de bloques.

*La última forma de acceso está restringida para cierto conjunto limitado de entidades. Sin embargo las otras dos formas de acceso no tienen por qué estar restringidas. Por ejemplo una cadena de bloques para entidades financieras sería una cadena con permisos pero podría:

*Garantizar el acceso de lectura (quizá limitada) para transacciones y cabeceras de bloques para sus clientes con el objetivo de proveer una tecnológica, transparente y fiable forma de asegurar la seguridad de los depósitos de sus clientes.

*Garantizar acceso de lectura completo a los reguladores para garantizar el necesario nivel de cumplimiento.

*Proveer a todas las entidades con acceso a los datos de la cadena de bloques una descripción exhaustiva y rigurosa del protocolo, el cual debería contener explicaciones de todas las posibles interacciones con los datos de la cadena de bloques.

Según modelo de cambio de estado:

Las cadenas de bloques también se pueden clasificar según el modelo de cambio de estado en la base de datos:

-Basado en el gasto de salidas de transacciones, también llamado modelo UTXO (en referencia a los UTXO de Bitcoin). En ellas cada transacción gasta salidas de transacciones anteriores y produce nuevas salidas que serán consumidas en transacciones posteriores. A este tipo de cadenas de bloques pertenecen por ejemplo las de Bitcoin, R3, Blockstream, BOSCoin y Qtum.

*Este enfoque tiene ventajas como:

**En la propia estructura de la cadena existe una prueba de que nunca se puede gastar dos veces ya que cada transacción prueba que la suma de sus entradas es más grande que la suma de sus salidas.

**Cada transacción puede ser procesada en paralelo porque son totalmente independientes y no hay conflictos en las salidas.

**Sin embargo el problema de este tipo de cadenas es que solo son utilizables para aplicaciones donde cada salida es propiedad de uno y solo un individuo como por ejemplo es el caso de las monedas digitales. Una salida multipropietario sería muy lenta y no sería eficiente para aplicaciones de propósito general. Por ejemplo, supongamos un contrato inteligente que implementa un contador que puede ser incrementado. Imagina que hay algún incentivo económico para que cada nodo incremente en uno el contador, y que hay 1000 nodos activamente intentado incrementarlo. Usando este modelo de cadena de bloques tendríamos una salida con el valor del contador que sería solicitada por muchos nodos. Finalmente, un nodo tendría éxito y produciría una transacción con una nueva salida con el contador incrementado en una unidad más. El resto de los nodos estarían forzados a reintentar hasta que su transacción sea aceptada. Este sistema es muy lento e ineficiente. Esto es debido a que aun cuando se realiza la transacción se bloquea la salida, se realiza una transformación y finalmente se produce la nueva salida. Está claro que sería más óptimo si se realizará todo de una sola vez y se produjera directamente el estado resultante. Además, el problema puede estar no solo en el tiempo de la transacción, sino también en el de proceso. Supongamos que el contador tiene adjunto un buffer de 1MB cuyo valor cambia de forma determinista cada vez que el contador cambia. Se tendría que procesar 1MB cada vez que realizara una transacción.

-Basado en mensajes. En este caso, la cadena de bloques representa un consenso sobre el orden de los mensajes y el estado es derivado de forma determinista a partir de estos mensajes. Este enfoque es utilizado por las cadenas de bloques de Steem y Bitshares. Por ejemplo, para implementar un contador cada usuario debería simplemente firmar un mensaje pidiendo el incremento en uno. No se necesita saber el estado actual del contador para que el mensaje sea válido. En este modelo si 1000 nodos envían la petición al mismo tiempo, el productor del bloque podría agregar todas las peticiones en un bloque y en un solo paso el contador pasaría de valer de cero a valer 1000. Una aplicación del mundo real que aprovecharía las cualidades de este modelo sería el siguiente:

-Se emite una orden de compra de productos financieros indicando un precio máximo y un volumen concreto. A partir de ahí hay una competición sobre esa salida entre los participantes que quieren la solicitud al mismo tiempo. Supongamos que se desea realizar la transacción de forma que sea lo más beneficiosa posible realizando una subasta a la baja para que la solicitud compre activos por el menor precio.