La estandarización puede proporcionar los beneficios de las «economías de escala» y garantizar una interoperabilidad efectiva entre diferentes sistemas y plataformas blockchain.
También proporciona las condiciones para evitar comportamientos anticompetitivos y realizar operaciones de mercado de manera eficiente. Sin embargo, existen preocupaciones con respecto a un enfoque excesivamente prescriptivo que podría evitar la innovación en esta etapa temprana de madurez de DLT.
Tomando un enfoque abstracto, un caso de uso de DLT se puede dividir en dos capas abstractas: la capa de libro mayor y las capas de aplicaciones. La capa de libro mayor se basa en libros de código abierto, descargables desde repositorios públicos como github.com, o en libros de contabilidad patentados desarrollados por desarrolladores / vendedores individuales. Uno puede preguntarse si la estandarización es realmente necesaria en el nivel contable. Existen varios tipos de contabilidad por una razón, ya que varían unos de otros por características como el mecanismo de consenso, el lenguaje de codificación de contrato inteligente, los requisitos de recursos y más. También varían según su idoneidad para casos de uso específicos.
Por ahora, es técnicamente imposible que los libros de contabilidad de diferentes tipos de redes utilicen la misma cadena. Por lo tanto, la estandarización de la capa de libro mayor no debe centrarse en reducir todas las variantes a un tipo de libro mayor común o en un tipo de cadena común, sino más bien en promover la interoperabilidad entre diferentes DLTs. Una posibilidad es crear un método estándar para vincular o hacer referencia a registros que existen en diferentes cadenas creadas por diferentes libros de contabilidad. Se puede utilizar una técnica llamada «intercambio atómico» cuando al menos dos partes desean intercambiar activos digitales sin intermediarios. Teóricamente se puede implementar en cualquier cadena, pero es más fácil entre los libros que comparten algunas características (como el mismo algoritmo de consenso).
«Los estándares facilitan la interoperabilidad. Además, al establecer reglas básicas, terminología común, métodos de desarrollo y técnicas de medición, los estándares permiten el desarrollo de innovaciones de seguimiento y su difusión. La estandarización también puede ayudar a crear masa crítica en las etapas formativas de un mercado determinado. Sin embargo, establecer estándares también puede plantear riesgos: pueden conducir a un bloqueo indeseable en tecnologías subóptimas y permitir a los titulares crear barreras para la entrada al mercado con implicaciones negativas para la innovación «
Fuente: Innovation policy platform.
Entonces, la estandarización a nivel de aplicación es donde la industria debería enfocarse. Hay que tener en cuenta que hasta la fecha, todas las aplicaciones son desarrollos patentados. Si bien las DLT puede desintermediar los repositorios jerárquicos de nivel superior, la propiedad intelectual sigue siendo de los desarrolladores, creando así un bloqueo al proveedor. Cuando la aplicación se desarrolla internamente y sirve a una sola organización, esto puede no ser un problema. Sin embargo, en los casos en que la aplicación sirve a múltiples entidades (a veces competidoras), el bloqueo del proveedor es una situación que debe evitarse. El bloqueo de proveedores crea dependencia, reduce la diversidad y aumenta los riesgos operativos. Aquí es donde la estandarización puede aportar un beneficio real. Para empezar, hay ciertas funciones, como la identidad y el pago, que son comunes a la gran mayoría de los casos de uso. Esas funciones serían los primeros candidatos para la estandarización. Otras funciones pueden ser más específicas de caso de uso y puede tener sentido diseccionarlas a lo que uno puede definir como MVP (Producto mínimo viable) y VAF (Características de valor agregado). La estandarización de los MVP permitiría a los desarrolladores competir en los VAF, diferenciando su oferta de la de los demás.
Un enfoque común hacia la estandarización sería construir una RA (Arquitectura de referencia) abstracta que defina los bloques de construcción básicos y sus relaciones / puntos de intercambio de información. La siguiente fase sería observar la funcionalidad de cada bloque de construcción y definirla utilizando máquinas de estado o diagramas de flujo para todas las operaciones del ciclo de vida de toda la aplicación, que luego constituyen el funcionamiento estándar de dichos bloques para los que los desarrolladores deberían construir. No es raro que cuando se agregan casos de uso (MVP), se descubren puntos en común, lo que hace que ciertos desarrollos en un MVP sean reutilizables en otro. Este es el enfoque seguido por iCommunity Labs, que busca crear una RA (arquitectura de referencia) que sirva como plataforma de ecosistema para el desarrollo rápido de casos de uso a partir de la reutilización de otros ya creados, o de algunos de sus bloques de construcción existentes.
INTEROPERABILIDAD
Otro aspecto importante de la estandarización es la portabilidad de las aplicaciones entre tipos de libro mayor. Claramente, cada libro mayor tiene una interfaz algo diferente hacia el norte (libro mayor a aplicación) que requiere, como mínimo, diferentes API (AKA «segunda capa»). Sin embargo, con el uso de diferentes lenguajes de codificación para contratos inteligentes por cada DLT, dicha portabilidad puede requerir la reescritura de los contratos que, hasta la fecha, es una tarea manual. Sería beneficioso desarrollar una plantilla estándar abstracta de contrato inteligente que luego pueda compilarse automáticamente en el libro de contabilidad de su elección. Aunque pueda parecer descabellado el combinar la portabilidad de las aplicaciones entre los tipos de DLTs y estandarizar la vinculación o los registros de referencia entre cadenas, permitiriamos la interoperabilidad de las aplicaciones que se ejecutan en cualquier tipo de de red.
La portabilidad de datos también es relevante en un contexto de portabilidad de aplicaciones. Además, no hay estándares para el intercambio de datos entre DLTs (a través de la interoperabilidad entre cadenas) que pueden incluir claves públicas, valores hash, tokens u otros datos administrados por contrato inteligente.
Mirando los diferentes casos de uso, sería conveniente afirmar que la mayoría de ellos se beneficiarán de la adopción de un enfoque estandarizado para el desarrollo de aplicaciones. No se recomienda, en esta etapa, elegir el tipo de DLT (por ejemplo, Ethereum, HyperLedger, una DLT patentada o cualquier otra disponible para su uso) por tipo de caso de uso, pero se recomienda que la industria desarrolle pautas que destaquen los beneficios y desventajas de las diferentes DLT y, por lo tanto, su nivel de idoneidad para casos de uso de diferentes naturalezas. Desde hipotecas electrónicas hasta cadenas de suministro farmacéuticas y generación de energía distribuida hasta préstamos del sector público, todas las aplicaciones pueden aprovechar las reducciones de costos y la interoperabilidad inherente a las interfaces estandarizadas. Un beneficio central considerado con las interfaces estándar es la portabilidad de soluciones entre proveedores de servicios alternativos.
