> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/contributor/contributor-pt/catalyst/glossary.md).

# Glossário

#### Catalyst

[Catalyst](https://github.com/decentraland/catalyst) é o nome dado ao **Pacote de Serviços Decentraland**, cada Catalyst [nó](https://decentraland.github.io/catalyst-monitor) expõe um conjunto de serviços que funcionam como a espinha dorsal da plataforma e também expõe uma [API](https://decentraland.github.io/catalyst-api-specs/).

#### Bootstrap

Quando o Catalyst é iniciado, o nó terá um `Bootstrapping` estado enquanto busca conteúdo de outros Catalysts até alcançar os demais. E então transita para o próximo estado `Syncing` no qual está pronto para servir conteúdo.

#### Catalyst Client

[Biblioteca](https://github.com/decentraland/catalyst-client) que pode ser usada para interagir com os servidores Catalyst. Ela permite tanto buscar dados quanto implantar novas entidades no servidor especificado.

#### Entity

Tipo de dado, definido com [schemas](https://github.com/decentraland/common-schemas), que não pode ser armazenado na blockchain por causa do seu tamanho. Alguns dos atuais [tipos suportados](https://github.com/decentraland/common-schemas/blob/main/src/platform/entity.ts#L13) são os seguintes:

* [Wearable](https://github.com/decentraland/common-schemas/blob/main/src/platform/item/wearable/wearable.ts)
* [Emote](https://github.com/decentraland/common-schemas/blob/main/src/platform/item/emote/emote.ts)
* [Cena](https://github.com/decentraland/common-schemas/blob/main/src/platform/scene/scene.ts)
* [Perfil](https://github.com/decentraland/common-schemas/blob/main/src/platform/profile/profile.ts)
* [Stores](https://github.com/decentraland/common-schemas/blob/main/src/dapps/store.ts)
* [Outfits](https://github.com/decentraland/common-schemas/blob/main/src/platform/outfits/outfits.ts)

#### Implementação

Instâncias de Entities criadas no Content Server e identificadas com um único [EntityId](https://github.com/decentraland/common-schemas/blob/main/src/platform/entity.ts#L31). Deployments podem ser de qualquer [tipo de Entity](https://github.com/decentraland/common-schemas/blob/main/src/platform/entity.ts#L13).

#### Deploy com Falha

Instância de uma Entity implantada em um Content Server que falhou em passar pelas [Validações de Conteúdo](https://adr.decentraland.org/adr/ADR-51). As validações são implementadas no [validador de conteúdo](https://github.com/decentraland/content-validator) .

#### Entidade Ativa

Uma entidade que está atualmente implantada em um pointer, portanto todas as entidades ativas representam o conteúdo vivo de Decentraland: scenes, perfis, wearables, etc.

#### Ponteiro

Os ponteiros são os ids ou locais aos quais um Deployment pertence. Seu formato é diferente com base no `tipo de Entity`, por exemplo:

* **Wearables**: Usa URN como ponteiros `urn:decentraland:ethereum:collections-v1:dg_atari_dillon_francis:gerald_patchwork_knit_sweater`
* **Scenes**: Usa parcels ou array de parcels como ponteiros, por exemplo `--10,20` ou `[(0,0), (0,1), (0,-1)]`
* **Profiles**: Usa um endereço de Wallet como ponteiro `0xb01ddb6d4c89314f74a32dfc2f3bd0f8311a6d75`
* **Stores**: Usa uma URN como ponteiro `urn:decentraland:off-chain:marketplace-stores:{wallet}`
* **Outfits**: Usa um endereço de Wallet como ponteiro, sufixado por `:outfits`, `0xb01ddb6d4c89314f74a32dfc2f3bd0f8311a6d75:outfits`

#### URN

[URN](https://en.wikipedia.org/wiki/Uniform_Resource_Name) significa Uniform Resource Name. Elas são usadas como identificadores únicos globais para assets em todos os projetos do Metaverse.

* Resolvedor de URN: <https://github.com/decentraland/urn-resolver>
* Namespace de URN: <https://github.com/common-metaverse/urn-namespaces>

#### Servidor de conteúdo

O [Servidor de conteúdo](https://github.com/decentraland/catalyst/tree/main/content) é uma parte do nó Catalyst encarregada de gerenciar o armazenamento descentralizado dos Deployments de Entities. Atualmente, todo o conteúdo armazenado em um Content Server é sincronizado com o restante dos Catalysts da DAO.

#### Lambdas

O [Lambdas](https://github.com/decentraland/catalyst/tree/main/lambdas) O Service faz parte do nó Catalyst que funciona como uma camada de reconciliação entre os Content Servers e a Blockchain, sanitizando o conteúdo, validando a propriedade e ajudando a recuperar informações para os clientes Catalyst.

#### Sincronização

Os Content Servers oferecem a possibilidade de implantar conteúdo neles. Eles também garantem que qualquer conteúdo implantado nos outros Catalysts da DAO esteja disponível lá também. Resolver isso é chamado de **sincronização**.

#### SNAPSHOT de Conteúdo

Um conjunto de todas as Entidades Ativas de um tipo específico em um [Content Server](#content-server). Esses content snapshots são usados para sincronizar conteúdo entre nós Catalyst.

#### Realm

Ao se conectar ao Decentraland, você só seria capaz de interagir com Peers conectados ao mesmo Realm. Como nomes amigáveis, os Realms usam nomes de deuses gregos como Hela ou Loki. Cada realm é determinado por um único [Catalyst Node](https://decentraland.github.io/catalyst-monitor/).

#### Peer

Um usuário conectado ao Decentraland.

#### Lighthouse

O [Lighthouse](https://github.com/decentraland/lighthouse) é o nome usado para se referir à versão anterior do Communications Service hospedado nos nós Catalyst e usado para agrupar usuários em uma rede P2P. As principais responsabilidades eram determinar quais são os candidatos para uma conexão P2P e fazer o signaling WebRTC para estabelecer a conexão. A maior parte dessa lógica era feita por meio de dois componentes externos: o PeerJS Server (conecta [WebRTC](https://webrtc.org/) peers) e Archipelago (recebe as posições dos usuários e os agrupa em ilhas).

#### Backend for Frontend (também conhecido como BFF)

O [BFF](https://github.com/decentraland/explorer-bff) Service foi criado para resolver as necessidades do cliente e permitir um desenvolvimento mais rápido de novos recursos sem quebrar as APIs existentes. No contexto do Catalyst Communication Service, ele ficará encarregado de gerenciar a sinalização P2P e, assim, substituir o Lighthouse.

#### Catalyst Owner

A [Catalyst Owner](https://github.com/decentraland/catalyst-owner) é um indivíduo ou organização que opera um nó Catalyst. Para adicionar um nó Catalyst à rede DAO, uma [proposta](https://governance.decentraland.org/?type=catalyst) precisa ser submetida e os nós da DAO representam a rede confiável da Decentraland.

#### Serviço Archipelago

O [Serviço Archipelago](https://github.com/decentraland/archipelago-service) anteriormente era uma biblioteca usada pelo Lighthouse. Este serviço terá a mesma responsabilidade que a biblioteca tinha: agrupar peers em clusters para que possam se comunicar de forma eficiente entre si. Cada cluster é chamado de ilha. Por outro lado, o serviço também precisa ser capaz de balancear ilhas usando os transportes de comunicação disponíveis e seguindo um conjunto de [Catalyst Owner](https://github.com/decentraland/catalyst-owner) regras definidas, a fim de, por exemplo, usar LiveKit para uma ilha na cena Casino e P2P em uma Genesis Plaza.

#### Ilha

Cluster de peers conectados.

#### Transporte de Comunicação

Transporte é a tecnologia usada para compartilhar atualizações entre Peers conectados a uma Ilha.

#### Transporte P2P

Usa [WebRTC](https://webrtc.org/) conexões entre Peers, sem necessidade de infraestrutura extra para escalar, já que a carga fica do lado do cliente e os Servers apenas gerenciam a sinalização. A latência aumenta à medida que mais Peers são adicionados a uma Ilha. Há um limite para a quantidade de conexões WebRTC que um cliente pode ter, portanto, para ter ilhas maiores, são necessárias mais conexões indiretas (saltos) entre peers.

#### Transporte LiveKit

[LiveKit](https://livekit.io/) é um projeto de código aberto que oferece conferência escalável para múltiplos usuários via WebRTC. Em vez de fazer uma rede P2P, os Peers se conectam a uma Unidade de Encaminhamento Seletivo (SFU) encarregada de gerenciar o encaminhamento de mensagens e diferentes aspectos de qualidade da comunicação. As SFUs são a infraestrutura adicional necessária para fornecer comunicações de alto desempenho / alta qualidade entre multidões em cenas designadas.

#### Transporte WebSocket

O [Transporte WebSocket](https://github.com/decentraland/ws-room-service) é mais leve que o LiveKit, também requer um Server que gerencia o encaminhamento de mensagens por meio de salas WebSocket. As salas são equivalentes a ilhas. Este transporte oferece menos latência e melhor desempenho do que ilhas P2P, mas também requer a infraestrutura extra.

#### NATS

[NATS](https://nats.io/) é um message broker que permite a troca de dados e a comunicação entre serviços. No contexto do Catalyst Server, ele é usado para comunicar alguns dos serviços internos.

#### DAO

DAO significa "Decentralized Autonomous Organization". A DAO da Decentraland possui os smart contracts e ativos mais importantes que compõem a Decentraland – o LAND Contract, o Estates Contract, Wearables, Content Servers e o Marketplace. Ela também possui uma reserva substancial de MANA, o que lhe permite ser verdadeiramente autônoma e também subsidiar várias operações e iniciativas em toda a Decentraland.

<https://dao.decentraland.org/en/>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/contributor/contributor-pt/catalyst/glossary.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
