Por Craig Wright | 22 mayo 2023 | Monedas y sistemas alternativos
Descargue el código correspondiente como archivo ZIP/RAR aquí .
El concepto de token no fungible (NFT) se ha utilizado para crear artículos asociados con la especulación y el lavado de dinero (Wilson et al., 2022). Sin embargo, como espero demostrar en esta publicación, la misma tecnología puede simplificar significativamente la implementación de muchas aplicaciones existentes, incluso en contabilidad y comercio. En el ejemplo de hoy, veremos algunos de los pasos para crear un conocimiento de embarque (BoL) que vincula las identidades de las corporaciones a una serie de facturas y usa NFT para hacer referencia y comercializar los certificados de propiedad asociados con bienes y productos básicos.
En este ejemplo, LDAP se utiliza para buscar e indexar los nombres corporativos y las claves de identidad asociadas a ellos a través de un certificado X.509 firmado por una autoridad certificadora (CA). Tenga en cuenta que comenzaremos a revisar el ejemplo sección por sección y, a medida que lo haga, el código se vinculará en archivos que se pueden descargar. Las imágenes del entorno de laboratorio colaborativo de Google se conectarán al código fuente. Las diversas áreas requerirán actualización para que el código pueda incorporar todos los cambios necesarios para la implementación en los sistemas existentes. Cuando sea necesario, se dejará a la persona que descarga los archivos implementar cualquier otra biblioteca utilizada en la aplicación local con la que está integrado.
Tenga en cuenta que he hecho varias suposiciones con respecto a los sistemas existentes con los que se ejecutará. Asimismo, acceder a claves de servidores LDAP y convertirlas a direcciones BSV, usar TXID para números de conocimiento de embarque, etc., implica un conocimiento detallado de los sistemas existentes y operaciones criptográficas complejas, que deben personalizarse en función de las necesidades individuales del negocio que implementa el solución.
Código 1 – Marco inicial
A partir de aquí, debemos considerar la conexión al servidor LDAP. La conexión se puede realizar utilizando una variedad de técnicas de autenticación y puede implicar un nombre de usuario y una contraseña, como se muestra en la figura a continuación (Código 2). Alternativamente, una conexión puede basarse en un certificado digital o en una metodología de autenticación basada en token (Código 3).
Código 2: conexiones LDAP
No todos los servidores LDAP admiten la autenticación basada en certificados utilizando el mecanismo externo Simple Authentication and Security Layer (SASL) (Zeilenga & Melnikov, 2006), que hace que el servidor determine la identidad de autorización en función del certificado presentado por el cliente durante un protocolo de enlace SSL/TLS exitoso. . Alternativamente, se pueden utilizar otras formas de autenticación basada en certificados. Por ejemplo, en una publicación posterior, demostraré cómo usar una dirección de Bitcoin como una forma de autenticación tokenizada, que está más allá del alcance de esta publicación.
Código 3: conexiones LDAP basadas en certificados
Creación de NFT para nuestros productos
Los sistemas de tokens no fungibles (NFT) no necesitan representar artículos de intercambio, pero pueden ser un medio para crear el mercado de productos y las referencias de artículos a los que se hizo referencia en el lanzamiento original de Bitcoin en el mercado. El ejemplo de conocimiento de embarque proporcionado (Código 4) se acuña a un NFT (Código 5) que se puede transferir a medida que se mueven las mercancías o incluso si las mercancías se venden durante el tránsito.
Código 4 – Clase de conocimiento de embarque
Me ocuparé de documentar los otros aspectos del NFT al que se hace referencia. Pero antes que nada, señalaré que podemos crear un simple token de conocimiento de embarque transferible utilizando la información de la que ya estamos hablando. Además, tenga en cuenta que estoy usando un solo satélite y no he tenido en cuenta las tarifas de minería u otras cosas que deben tenerse en cuenta en una implementación del mundo real. El sistema sería acuñado por las personas que crean los bienes, y el certificado de los bienes actúa como un certificado de propiedad que se transfiere y acuña en el documento de contrato del conocimiento de embarque.
Código 5 – Conocimiento de Embarque NFT
Con toda esta información, ahora podemos producir el token ‘GoodNFT’ que el fabricante de productos utilizará para crear una aplicación de token. Es importante tener en cuenta que para el método from_nft, he usado una función simulada utxo_from_nft que devuelve una salida de transacción no gastada simulada (UTXO). Cuando implemente una función de este tipo en una aplicación de envío del mundo real, la reemplazará con su función que consulta el conjunto de UTXO para un UTXO que representa el NFT. En la codificación del mundo real, también será necesario agregar el manejo de errores.
Código 6 –NFT que representa un certificado de propiedad adjunto a los bienes
Tenga en cuenta que la información utilizada puede ampliarse. He creado un conjunto simple de definiciones en diccionarios de datos que pueden entrar en más detalles, incluidos los números de serie, si es necesario. El enlace de la tabla hash distribuida (DHT) también podría proporcionar información adicional que haga referencia al elemento en particular. Un área, como marcas y números, se puede ampliar para incluir identificadores individuales para cada elemento. Un ejemplo sería un valor que haga referencia a un teléfono en particular si se vendieron varios teléfonos.
Implementación de tokens en Salesforce
En este ejemplo, no voy a entrar en todos los detalles de cómo hacer una billetera. A medida que analizo los ejemplos cada semana, la información que brindo gradualmente dará como resultado suficiente información para hacer cada etapa, pero solo hay un límite que uno puede hacer a la vez. Además, aunque me gustaría ver otras metodologías, incluidas las bases de datos de valores clave, ahora usaremos métodos ampliamente aceptados al acceder a un nodo de Bitcoin (BSV), incluidas bibliotecas como bsv o moneybutton/bsv.
Existen muchas metodologías para obtener transacciones, por lo que no las abordaré en esta publicación. Lo haré, en publicaciones posteriores, pero por ahora, diré que es principalmente un marcador de posición.
Código 7: cargar el NFT en SalesForce
A continuación, comenzaremos a agregar código para manejar las firmas de cada parte involucrada en el conocimiento de embarque.
Código 8: se debe firmar el conocimiento de embarque
Luego podemos comenzar a implementar el código de firma.
Código 9 – Firma del conocimiento de embarque
Para la siguiente parte, supondré que ya hemos recibido una transacción sin procesar guardada como un archivo binario, transaction.bin . Esto se lee como un vector de bytes y luego analiza el vector de bytes en una transacción de Bitcoin (BSV).
Código 10: un archivo VISUAL STUDIO C++ para leer el código en texto
En general, hay varios pasos involucrados en la creación de dicho sistema. Primero, será necesario desarrollar un sistema que monitoree la red o participe en un intercambio de verificación de pago simplificado (SPV) entre individuos. Luego, en las próximas semanas y meses, habrá un documento de una solución de billetera completa que se puede construir usando todo esto. La idea aquí es enseñarle lentamente cómo crear un sistema que acuñará un producto de un productor y le atribuirá un certificado de propiedad NFT. Al hacerlo, comenzaré a documentar cómo crear una aplicación de billetera SPV adecuada que se pueda usar para aceptar encabezados producidos por los mineros (también conocidos como nodos) en la red, y cómo se puede implementar con Bitcoin para crear soluciones del mundo real.
Un ejemplo que podríamos derivar de aquí es tomar el archivo guardado en “Código 10” y enviarlo a una aplicación EDI. Pero, como todos los programadores, soy perezoso. Usando el GoodNFT que acabo de diseñar, tomaremos la información de NFT que hemos pasado y la enviaremos a un documento de Aviso/Manifiesto de envío EDI. Para aquellos que no saben, la biblioteca pyx12 se puede usar para crear un documento EDI 856. EDI tiene estándares estrictos. Por lo tanto, será fundamental asegurarse de que cuando creamos un documento EDI 856 con los datos de nuestro GoodNFT, mapeamos todos los valores correctamente. Al hacerlo, se supondría que la información de la fuente se ingresó correctamente y que el fabricante sigue los estándares.
En el ejemplo del documento EDI 856 que se muestra a continuación, asumo que la marca de tiempo del bloque y los detalles de la transacción hacen referencia al momento de la liquidación en la transacción. Escuché de un tiempo de liquidación promedio de diez minutos para aplicaciones del mundo real. Por lo tanto, si bien los tiempos de transacción individuales podrían estar vinculados a NTP, esto es suficiente para lo que brindo de forma gratuita.
Código 11 – EDI de Bitcoin
Esta información nos permite crear facturas y órdenes de compra dentro de Salesforce (Código 12).
Código 12 – Volver a Salesforce
Pero, eso es todo lo que haré por esta noche. Entonces, para terminar, explicaré rápidamente un conocimiento de embarque y señalaré los diversos requisitos de dicho documento. Sin embargo, como habrá adivinado en la sección EDI, sigue siendo importante tener en cuenta que esta es un área compleja que requiere conocimientos especializados y algo más que codificación.
Explicaciones de un conocimiento de embarque
Un conocimiento de embarque (B/L) es un documento legal utilizado en el comercio internacional para acusar recibo de mercancías y proporcionar detalles sobre el envío. Los campos estándar que se encuentran comúnmente en un conocimiento de embarque incluyen los siguientes:
- Transportista: información sobre la parte o empresa que envía las mercancías.
- Consignatario: Información sobre la parte o empresa que recibe la mercancía.
- Transportista: Información sobre el transportista o empresa de transporte encargada de transportar la mercancía.
- Notificar a la Parte: Campo opcional para especificar un tercero a quien notificar sobre la llegada o el estado de las mercancías.
- Puerto de carga: El nombre del puerto donde se cargan las mercancías en el buque.
- Puerto de descarga: El nombre del puerto donde se descargarán las mercancías del buque.
- Embarcación/Viaje: Los detalles sobre el nombre de la embarcación y el número de viaje identifican la embarcación específica y el viaje en el que se transportarán las mercancías.
- Número de conocimiento de embarque: un identificador único asignado al conocimiento de embarque con fines de referencia y seguimiento.
- Descripción de los bienes: una descripción detallada de los bienes que se envían, incluido el tipo de bienes, la cantidad, el peso, el embalaje y cualquier instrucción especial o requisitos de manipulación.
- Marcas y Números: Marcas o etiquetas únicas en los empaques o contenedores utilizados para identificar y rastrear las mercancías.
- Peso bruto/Peso neto: El peso total de la mercancía, incluido el peso del embalaje (peso bruto) y el peso de la mercancía sola (peso neto).
- Medida: Las dimensiones o el tamaño del envío, incluidos el largo, el ancho y la altura.
- Cargos de flete: información sobre los cargos de flete asociados con el envío, incluida la moneda y las condiciones de pago.
- Incoterms: Los Términos Comerciales Internacionales (Incoterms) que especifican los derechos y responsabilidades del comprador y del vendedor con respecto al envío y entrega de los bienes.
- Fecha de envío: la fecha en que se cargan las mercancías en el buque.
- Firma: Firmas de los representantes autorizados del embarcador, transportista y consignatario, reconociendo su conformidad con los términos y condiciones del Conocimiento de Embarque.
Estos son los campos comúnmente utilizados en un conocimiento de embarque, pero el formato exacto y los lotes pueden variar según los requisitos específicos de la empresa naviera o las prácticas comerciales de los diferentes países. Tenga en cuenta que esta publicación de blog no es una solución definitiva para todos los resultados posibles. Además, algunas de las áreas en una descripción de bienes incluidas en nuestro GoodNFT pueden ampliarse para incluir lo siguiente:
- Tipo de mercancías: especifique la naturaleza o el tipo de mercancías que se envían, como productos electrónicos, textiles, maquinaria, mercancías perecederas, materiales peligrosos, etc. Esta información ayuda a determinar los requisitos adecuados de manipulación y almacenamiento.
- Cantidad: Indique la cantidad de mercancías que se envían. Esto podría incluir el número de unidades, paquetes, tarimas o contenedores.
- Peso: Indique el peso de la mercancía, que puede incluir peso bruto (peso total de la mercancía y embalaje) y peso neto (peso de la mercancía sin embalaje). Ayuda a determinar los costos de transporte y garantizar el cumplimiento de las restricciones de peso.
- Embalaje: Describa el embalaje utilizado para contener las mercancías, como cajas de cartón, tambores, jaulas o palés. Mencione cualquier instrucción de embalaje especial si es necesario.
- Dimensiones: si corresponde, incluya las medidas del envío, como largo, ancho y alto. Esta información ayuda en la asignación de espacio y en la determinación de la compatibilidad con el equipo de transporte.
- Marcas y números: especifique cualquier marca, número o etiqueta únicos asociados con el empaque o los contenedores. Estas marcas identifican y rastrean los productos a lo largo de la cadena de suministro. En nuestro ejemplo, los integraremos gradualmente para permitir un sistema de seguimiento global que rastree los bienes logísticos. Pero, este es solo el primer post.
- Instrucciones especiales: si existen instrucciones o requisitos de manejo específicos para los productos, como control de temperatura, ventilación, limitaciones de apilamiento o manejo frágil, deben mencionarse claramente.
- Códigos del Sistema Armonizado (HS): Incluya los códigos HS apropiados que clasifican las mercancías según los sistemas de codificación reconocidos internacionalmente. Los códigos del SA facilitan el despacho de aduanas y garantizan una categorización precisa de las mercancías con fines normativos y estadísticos.
Además, tenga en cuenta que no he incluido ningún detalle de aduana, que debería completarse en el código final.
Descargue el código correspondiente como archivo ZIP/RAR aquí .
Referencias
Wilson, KB, Karg, A. y Ghaderi, H. (2022). Prospección de tokens no fungibles en la economía digital: Partes interesadas y ecosistema, riesgo y oportunidad. Business Horizons , 65 (5), 657–670. https://doi.org/10.1016/j.bushor.2021.10.007
Zeilenga, K. y Melnikov, A. (2006). Capa de seguridad y autenticación simple (SASL) (Solicitud de comentarios RFC 4422). Grupo de Trabajo de Ingeniería de Internet. https://doi.org/10.17487/RFC4422