Empecemos por una verdad incómoda
La mayoría de los marketplaces no necesitan blockchain.
Craigslist, MercadoLibre, eBay: listar, buscar, mensajear, pagar con tarjeta. Nada de eso necesita una cadena, un Postgres y Stripe lo resuelven, y lo resuelven mejor. Si arrancás un proyecto en Soroban poniendo "marketplace" y "blockchain" en la misma frase sin preguntarte por qué, ya empezaste mal Tiburona, muy mal.
Entonces, ¿por qué vamos a construir un marketplace para aprender Soroban?
Porque un marketplace es el ejemplo más limpio que existe para aprender la única decisión que de verdad importa cuando construís sobre blockchain: qué tiene que vivir en la cadena, y qué no. Te obliga a encontrar la pieza, una sola, que justifica todo el resto y cuando la encontrás, vas a entender blockchain y en este caso Soroban de una forma que ningún "Hello World" te va a dar.
Así que este no es un tutorial de "cómo construir un marketplace en Soroban". Es un tutorial de cómo decidir qué va on-chain, usando un marketplace que vas a poder tocar., el código es lo sencillo, la decisión es el oro.
Qué vamos a construir
Un marketplace tipo Craigslist, pero descentralizado: un vendedor lista un producto, un comprador lo paga, y la propiedad se transfiere, fácil de describir, lo interesante es dónde metemos la cadena (sip, un producto triste y super quemado pero es lo que hay)
Primero los actores principales:
Los tres actores
- El vendedor. Publica un producto: nombre, precio, en que se paga, en patacones? en libra? . Quiere que, cuando alguien pague, la plata le llegue. No quiere depender de que una plataforma se la transfiera "cuando pueda".
- El comprador. Ve un producto, paga, y quiere quedárselo. No quiere pagar y que después el vendedor, o la plataforma, desaparezca con la plata.
- El contrato. Acá está la diferencia con la web tradicional. En un marketplace común, el tercero de confianza es la empresa: retiene la plata, decide cuándo soltarla, puede congelarla. En nuestro marketplace (sip, el tuyo y el miop, el nuestro que vamos a estar haciendo) ese tercero no es una empresa: es el contrato. Nadie lo controla a su favor, nadie puede pausarlo cuando le conviene, y hace exactamente lo que dice su código, ese es el actor que reemplaza a la plataforma.
Hay una cuarta cosa en juego: el token con el que se paga, puede ser USDC, por ejemplo. En Stellar ese token se maneja a través de algo que se llama Stellar Asset Contract (SAC); no te preocupes por el nombre ahora, lo vemos en las siguientes Partes.
El único momento que importa
Ahora, la pregunta que define todo el proyecto: ¿cuál es la única cosa que, si no estuviera en la cadena, rompería la promesa del marketplace?
No es el listado. No son las fotos. No es el buscador. Es esto:
El comprador paga y la propiedad se transfiere en la misma operación, sin que la plataforma toque la plata.
A esto se le llama un swap atómico: el pago y la transferencia pasan pegados, como una sola cosa). Todo el contrato que vamos a escribir existe, en el fondo, para que ese único momento salga bien.
Para entender por qué importa, imagina que lo haces en dos pasos separados. Primero el comprador paga. Después, en otra operación aparte, se transfiere la propiedad. ¿Qué pasa si entre el paso uno y el paso dos algo falla, o alguien hace trampa? El comprador pagó y no recibió nada. O el vendedor entrego y no cobro. Ese hueco entre los dos pasos es el lugar donde vive la confianza (esa confianza que no te dio tu ex).
Así funciona casi toda la web y está perfectamente bien: una empresa, con sus servidores, se para en ese hueco y se hace responsable de que nadie se quede con la plata de la otra persona. El precio es que hay que confiar en esa empresa. No porque un servidor sea malo, el 99% de las apps del mundo funcionan así y andan bárbaro, sino porque alguien tiene que ocupar ese lugar de confianza, y ese alguien sos vos confiando en ellos(de nuevo, acordate que paso con tu ex).
Un contrato inteligente borra ese hueco y acá hay que ser honestas: esto no es magia exclusiva de Soroban, es así como funcionan los contratos inteligentes en general, también en otras blockchains. El pago y la transferencia ocurren juntos, de forma atómica: o pasan las dos cosas, o no pasa ninguna. No hay un instante intermedio donde alguien pueda quedarse con algo que no le toca, así que no hace falta que ninguna empresa garantice nada: no queda nada que garantizar.
Lo que aporta Stellar (y Soroban, su plataforma de contratos) no es inventar la atomicidad, sino hacerla barata, rápida y pensada desde el día uno para mover plata y activos, por eso en esta oportunidad estoy eligiendo Stellar para esto, no porque sea la única cadena que puede.
Ese fantasma, el del comprador que paga y no recibe, es la razón por la que este marketplace vive en una cadena, todo lo demás es decoración (este comentario tan de backend)
Lo que va en la cadena (y lo que no)
Una vez que La Tenes Clara esa única promesa, decidir qué guardar en la cadena se vuelve casi mecánico, para cada dato que se te ocurra, te vas a realizar una sola pregunta: si esto no estuviera en la cadena, ¿alguien podría hacer trampa con la plata? Si la respuesta es sí, va on-chain. Si es no, va afuera.
Aplicando esa pregunta, on-chain queda solo lo mínimo:
- Quién es el dueño de cada producto.
- El precio, y en qué token se paga.
- El estado: disponible o vendido.
Y nada más. El título largo, la descripción, las fotos, las categorías, el buscador: todo eso vive afuera, en una base de datos común y corriente (Postgres, en este espacio no se acepta otra base) porque a nadie le hace falta protegerlo. (una palabra que vas a escuchar todo el tiempo: trustless. Quiere decir que no necesitás confiar en nadie en particular, porque las reglas las hace cumplir la red. Es un concepto de blockchain en general, no algo propio de Stellar.) A nadie lo estafan con la descripción de un producto. Te estafan con la plata. Y la plata es lo único que protegemos en la cadena.
Ese reparto: lo crítico y mínimo va para on-chain, lo pesado y cómodo va para off-chain, es la decisión de arquitecta que este artículo entero te quiere enseñar. El contrato que vamos a escribir en las siguientes Partes va a ser sorprendentemente chico (inserte chiste facil), y es a propósito: un buen contrato hace una sola cosa, la cosa que nadie más puede garantizar, y se corre del camino para todo lo demás.
En la próxima parte
Con la idea, los actores y el swap atómico claros, en las siguientes Partes voy a estar traduciendo todo esto a un contrato Soroban en Rust, empezando, como corresponde, por el estado: qué guarda el contrato, no es que las funciones se escriban solas (esa magia no existe) pero cuando tenes claro que se guarda y que tiene que estar siempre a salvo, las funciones que necesitas dejan de ser un misterio: el estado te dice cuáles te hacen falta y qué tienen que proteger.
En la próxima Parte vamos a abrir Rust y Soroban por primera vez.
Pero antes de escribir una línea de código, quería que entendieras algo: los buenos contratos no nacen de funciones. Nacen de decisiones.
Nos vemos en la Parte 2.
Top comments (1)
Muy buen post Eliii 🫶🏻❤️