As funções integradas otimizam o processo de prova. No entanto, cada prova é calculada a partir do layout. Para certos trabalhos de prova, as vantagens das funções integradas serão bastante reduzidas se o layout for ineficiente. Atualmente, existe uma pequena lista estática de layouts, e cada prova é computada com base no layout mais adequado dessa lista. Essa maneira de dispor listas estáticas tem duas desvantagens. Primeiro, há uma variedade limitada de layouts. Isso é ineficiente para a maioria dos trabalhos de prova e cria mecanismos de taxas complexos que impõem custos desnecessários aos usuários. Em segundo lugar, é difícil manter a lista manualmente. Uma vez que o número de builtins fica muito alto, a manutenção manual torna-se difícil e pode realmente atrapalhar o processo de provar builtins eficientes que suportam um grande número de nuances. Para resolver esses problemas, a equipe StarkWare está desenvolvendo um sistema de layout dinâmico em que os layouts são personalizados para cada prova de trabalho.
A pilha Cairo facilita comprovadamente a computação de uso geral compilando o código Cairo em instruções para arquiteturas de CPU compatíveis com STARK: a VM Cairo (doravante referida como CVM). Muitas das vantagens das CPUs de uso geral têm um custo inerente, e o CVM não é otimizado para algumas operações comuns. As funções de hash de Keccak, Pedersen e Poseidon são operações comuns, assim como operações de curva elíptica, verificação de intervalo (ou seja, verificar se um determinado número está dentro de um determinado intervalo de valores) e outros.
Para abordar a relativa ineficiência dos CVMs, a pilha do Cairo apresenta o conceito de built-ins para operações críticas: plug-ins que otimizam tais operações para provar a complexidade. Funções integradas podem ser comparadas a ASICs: ASICs são circuitos integrados específicos de aplicativos e funções integradas são restrições algébricas (AIR) específicas de aplicativos. Se você não sabe ou não se lembra do que é o AIR, ele será abordado brevemente mais adiante neste artigo; leia este artigo para obter mais detalhes.
Resumindo, a complexidade da prova está relacionada (aproximadamente linear) a recursos chamados de unidades de rastreamento, e as funções integradas simplificam as provas de operações específicas usando muito menos unidades de rastreamento do que o Cairo VM.
Agora que os benefícios das funções integradas foram explicados, fica claro por que as funções integradas foram desenvolvidas para muitas operações comuns. Isto é mais fácil dizer do que fazer. O processo atual de introdução de novos built-ins no Starknet consiste nas seguintes etapas:
Escrevendo AIR
Integrar com o provador criando um novo layout (descrito abaixo)
Integre-se ao Starknet, ou seja, modifique sua base de código e ferramentas de desenvolvedor para usar novas funções integradas
Além dos desafios de escrever o AIR, há muito espaço para melhorias nas duas fases restantes. Este artigo avançado descreverá com mais detalhes as funções incorporadas do AIR como específicas do aplicativo, os problemas acima e os planos futuros.
Funções integradas: AIR específico do aplicativo
AIR é um acrônimo para representação intermediária algébrica. Neste e em outros artigos da StarkWare, o AIR é um sistema polinomial para representar máquinas virtuais. Por exemplo, Cairo leva o nome de CPU AIR: um sistema polinomial que representa uma arquitetura de CPU específica. As soluções desse sistema polinomial representam transições de estado eficientes, denominadas trajetórias de execução algébrica eficientes (AETs).
STARK prova que o funcionamento da máquina virtual está correto ao provar que a trajetória de execução correspondente a um determinado AIR é válida. Grosso modo, uma trajetória de execução é uma tabela de números, e o protocolo STARK prova que esses números juntos resolvem um sistema polinomial.
A mesma operação pode ser calculada de várias maneiras, algumas das quais são mais eficientes. Neste artigo, a complexidade da prova depende basicamente do tamanho da trilha, ou seja, do número de células da trilha na tabela. Como os rastreamentos são gerados para o AIR, o AIR é projetado para aplicativos para reduzir significativamente os rastreamentos de execução para cálculos específicos. As funções integradas são AIR especializadas e otimizadas para o aplicativo.
A tabela abaixo mostra as melhorias de eficiência para funções internas específicas (todas em produção).
Trajetória traçada: presente e futuro
Conforme mencionado anteriormente, AET é aproximadamente uma tabela de números que representa a ordem das etapas na máquina virtual codificada (ou seja, a execução do programa). Para calcular a prova, o provador executa o protocolo STARK na trilha de execução do AIR associado.
Acima, introduzimos funções integradas como AIR específico do aplicativo, projetado para minimizar a complexidade das provas, reduzindo o número de unidades de rastreamento necessárias para codificar cálculos. No entanto, se as funções incorporadas forem integradas aleatoriamente no Starknet, muitas unidades de trajetória podem ser desperdiçadas e os benefícios esperados serão reduzidos. Vamos explicar em detalhes abaixo.
Resumindo, o layout da trilha é a atribuição de células de trilha a diferentes "componentes". Neste artigo, esses componentes são o CVM e as funções integradas. Especificamente, o layout especifica o número relativo de células de trilha que cada componente obtém. (Construções de layout são sempre usadas para simplificar a validação. Para saber mais, leia a seção "Simplicidade" deste post).
O ponto principal é que a complexidade da prova depende do número total de células de trilha alocadas pelo layout, e a alocação de células de trilha pode ser maior do que o realmente necessário. Por exemplo, para demonstrar a ordem das etapas de CVMs, um layout que atribui apenas células de rastreamento a componentes CVM é aproximadamente duas vezes mais eficiente que um layout que atribui metade das células de rastreamento a funções internas do Poseidon. Em conclusão, um layout adequado pode reduzir bastante a complexidade de provar um determinado cálculo.
Atualmente, existe uma lista de layouts mantida manualmente que cresce com o tempo por dois motivos principais:
As funções integradas só podem ser usadas para o layout da unidade de trilha atribuída a elas. Portanto, adicionar integrados requer pelo menos um novo layout.
Um layout feito sob medida para executar o código Cairo otimiza a alocação de células. Portanto, a otimização de casos de uso em células geralmente requer novos layouts.
O código para o provador e validador (validadores Solidity e Cairo) é configurado de acordo com a lista de layout.
À medida que os builtins Keccak e Poseidon foram adicionados, tornou-se cada vez mais difícil manter as listas de layout pequenas o suficiente para acomodar muitos builtins e manter a maioria dos blocos Starknet executando com eficiência. Além disso, espera-se que a eficiência caia significativamente conforme os built-ins adicionais são introduzidos, uma vez que o layout deve levar em conta as muitas combinações e proporções possíveis entre os built-ins.
A equipe StarkWare está atualmente trabalhando para melhorar o sistema abandonando listas de layout pré-fabricadas em favor de "layouts dinâmicos", que são personalizações instantâneas para cada execução do código do Cairo. O Layout Dinâmico sempre fará a alocação mais proporcional para o trabalho de verificação em questão. Do ponto de vista da engenharia, o suporte à digitação dinâmica exigiria mudanças consideráveis na base do código. No entanto, a equipe StarkWare espera simplificar a camada de prova do Starknet, aproveitando o layout dinâmico, a utilização aprimorada da unidade de trilha e a melhor utilização dos provadores.
Com layouts dinâmicos, o incômodo de manter manualmente muitos embutidos desaparece, simplificando o processo de integração de mais novos embutidos no Starknet.
Layout Dinâmico e Taxas
Um dos propósitos das taxas de transação é cobrar dos usuários o custo marginal do protocolo incorrido pelas transações. Como a unidade das taxas de transação é a moeda, o mecanismo de taxa envolve a conversão de recursos (por exemplo, etapas da máquina virtual, funções integradas, dados de chamada, gás Ethereum) em tokens (por exemplo, STRK, ETH).
Atualmente, como os provadores cobram taxas com base no total de rastreamentos, e não nas taxas de utilização, os recursos desperdiçados são arcados pelos usuários. O layout dinâmico melhorará a utilização da unidade de rastreamento, reduzindo assim a cobrança de taxas de transação "desnecessárias" (incluindo o consumo de recursos não causado diretamente pelas transações do usuário).
Integração de função interna do Starknet
Neste ponto, a integração de funções incorporadas está aquém da última etapa, que é modificar a base de código Starknet para realizar o uso prático. A extensão da modificação do código está relacionada ao aplicativo de layout e é necessário modificar o código para garantir que o sistema operacional Starknet chame funções integradas quando possível. Por exemplo, o sistema operacional Starknet chama a função hash Poseidon durante a execução do código Cairo e, ao mesmo tempo, chama a função interna Poseidon.
Semelhante aos layouts, os internos do Starknet agora podem ser suportados manualmente. No entanto, ao contrário do caso do layout, esse suporte manual não é uma barreira para a integração, embora existam muitas funções integradas. Em outras palavras, o suporte a builtins do Starknet não é uma barreira para a integração, o layout dinâmico realmente abrirá o caminho para a criação e integração de builtins adicionais.
Resumir
Neste artigo, explicamos o que são funções integradas, seus benefícios, os desafios envolvidos e os planos da StarkWare. O foco atual está no layout dinâmico, que não apenas melhorará a eficiência do processo de prova, mas também facilitará a integração de novos built-ins.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Benefícios e desafios das funções integradas do Starknet
Original: Builtins e layouts dinâmicos
Tradução e revisão: "StarkNet Chinese Community"
Resumo
As funções integradas otimizam o processo de prova. No entanto, cada prova é calculada a partir do layout. Para certos trabalhos de prova, as vantagens das funções integradas serão bastante reduzidas se o layout for ineficiente. Atualmente, existe uma pequena lista estática de layouts, e cada prova é computada com base no layout mais adequado dessa lista. Essa maneira de dispor listas estáticas tem duas desvantagens. Primeiro, há uma variedade limitada de layouts. Isso é ineficiente para a maioria dos trabalhos de prova e cria mecanismos de taxas complexos que impõem custos desnecessários aos usuários. Em segundo lugar, é difícil manter a lista manualmente. Uma vez que o número de builtins fica muito alto, a manutenção manual torna-se difícil e pode realmente atrapalhar o processo de provar builtins eficientes que suportam um grande número de nuances. Para resolver esses problemas, a equipe StarkWare está desenvolvendo um sistema de layout dinâmico em que os layouts são personalizados para cada prova de trabalho.
A pilha Cairo facilita comprovadamente a computação de uso geral compilando o código Cairo em instruções para arquiteturas de CPU compatíveis com STARK: a VM Cairo (doravante referida como CVM). Muitas das vantagens das CPUs de uso geral têm um custo inerente, e o CVM não é otimizado para algumas operações comuns. As funções de hash de Keccak, Pedersen e Poseidon são operações comuns, assim como operações de curva elíptica, verificação de intervalo (ou seja, verificar se um determinado número está dentro de um determinado intervalo de valores) e outros.
Para abordar a relativa ineficiência dos CVMs, a pilha do Cairo apresenta o conceito de built-ins para operações críticas: plug-ins que otimizam tais operações para provar a complexidade. Funções integradas podem ser comparadas a ASICs: ASICs são circuitos integrados específicos de aplicativos e funções integradas são restrições algébricas (AIR) específicas de aplicativos. Se você não sabe ou não se lembra do que é o AIR, ele será abordado brevemente mais adiante neste artigo; leia este artigo para obter mais detalhes.
Resumindo, a complexidade da prova está relacionada (aproximadamente linear) a recursos chamados de unidades de rastreamento, e as funções integradas simplificam as provas de operações específicas usando muito menos unidades de rastreamento do que o Cairo VM.
Agora que os benefícios das funções integradas foram explicados, fica claro por que as funções integradas foram desenvolvidas para muitas operações comuns. Isto é mais fácil dizer do que fazer. O processo atual de introdução de novos built-ins no Starknet consiste nas seguintes etapas:
Escrevendo AIR
Integrar com o provador criando um novo layout (descrito abaixo)
Integre-se ao Starknet, ou seja, modifique sua base de código e ferramentas de desenvolvedor para usar novas funções integradas
Além dos desafios de escrever o AIR, há muito espaço para melhorias nas duas fases restantes. Este artigo avançado descreverá com mais detalhes as funções incorporadas do AIR como específicas do aplicativo, os problemas acima e os planos futuros.
Funções integradas: AIR específico do aplicativo
AIR é um acrônimo para representação intermediária algébrica. Neste e em outros artigos da StarkWare, o AIR é um sistema polinomial para representar máquinas virtuais. Por exemplo, Cairo leva o nome de CPU AIR: um sistema polinomial que representa uma arquitetura de CPU específica. As soluções desse sistema polinomial representam transições de estado eficientes, denominadas trajetórias de execução algébrica eficientes (AETs).
STARK prova que o funcionamento da máquina virtual está correto ao provar que a trajetória de execução correspondente a um determinado AIR é válida. Grosso modo, uma trajetória de execução é uma tabela de números, e o protocolo STARK prova que esses números juntos resolvem um sistema polinomial.
A mesma operação pode ser calculada de várias maneiras, algumas das quais são mais eficientes. Neste artigo, a complexidade da prova depende basicamente do tamanho da trilha, ou seja, do número de células da trilha na tabela. Como os rastreamentos são gerados para o AIR, o AIR é projetado para aplicativos para reduzir significativamente os rastreamentos de execução para cálculos específicos. As funções integradas são AIR especializadas e otimizadas para o aplicativo.
A tabela abaixo mostra as melhorias de eficiência para funções internas específicas (todas em produção).
Trajetória traçada: presente e futuro
Conforme mencionado anteriormente, AET é aproximadamente uma tabela de números que representa a ordem das etapas na máquina virtual codificada (ou seja, a execução do programa). Para calcular a prova, o provador executa o protocolo STARK na trilha de execução do AIR associado.
Acima, introduzimos funções integradas como AIR específico do aplicativo, projetado para minimizar a complexidade das provas, reduzindo o número de unidades de rastreamento necessárias para codificar cálculos. No entanto, se as funções incorporadas forem integradas aleatoriamente no Starknet, muitas unidades de trajetória podem ser desperdiçadas e os benefícios esperados serão reduzidos. Vamos explicar em detalhes abaixo.
Resumindo, o layout da trilha é a atribuição de células de trilha a diferentes "componentes". Neste artigo, esses componentes são o CVM e as funções integradas. Especificamente, o layout especifica o número relativo de células de trilha que cada componente obtém. (Construções de layout são sempre usadas para simplificar a validação. Para saber mais, leia a seção "Simplicidade" deste post).
O ponto principal é que a complexidade da prova depende do número total de células de trilha alocadas pelo layout, e a alocação de células de trilha pode ser maior do que o realmente necessário. Por exemplo, para demonstrar a ordem das etapas de CVMs, um layout que atribui apenas células de rastreamento a componentes CVM é aproximadamente duas vezes mais eficiente que um layout que atribui metade das células de rastreamento a funções internas do Poseidon. Em conclusão, um layout adequado pode reduzir bastante a complexidade de provar um determinado cálculo.
Atualmente, existe uma lista de layouts mantida manualmente que cresce com o tempo por dois motivos principais:
As funções integradas só podem ser usadas para o layout da unidade de trilha atribuída a elas. Portanto, adicionar integrados requer pelo menos um novo layout.
Um layout feito sob medida para executar o código Cairo otimiza a alocação de células. Portanto, a otimização de casos de uso em células geralmente requer novos layouts.
O código para o provador e validador (validadores Solidity e Cairo) é configurado de acordo com a lista de layout.
À medida que os builtins Keccak e Poseidon foram adicionados, tornou-se cada vez mais difícil manter as listas de layout pequenas o suficiente para acomodar muitos builtins e manter a maioria dos blocos Starknet executando com eficiência. Além disso, espera-se que a eficiência caia significativamente conforme os built-ins adicionais são introduzidos, uma vez que o layout deve levar em conta as muitas combinações e proporções possíveis entre os built-ins.
A equipe StarkWare está atualmente trabalhando para melhorar o sistema abandonando listas de layout pré-fabricadas em favor de "layouts dinâmicos", que são personalizações instantâneas para cada execução do código do Cairo. O Layout Dinâmico sempre fará a alocação mais proporcional para o trabalho de verificação em questão. Do ponto de vista da engenharia, o suporte à digitação dinâmica exigiria mudanças consideráveis na base do código. No entanto, a equipe StarkWare espera simplificar a camada de prova do Starknet, aproveitando o layout dinâmico, a utilização aprimorada da unidade de trilha e a melhor utilização dos provadores.
Com layouts dinâmicos, o incômodo de manter manualmente muitos embutidos desaparece, simplificando o processo de integração de mais novos embutidos no Starknet.
Layout Dinâmico e Taxas
Um dos propósitos das taxas de transação é cobrar dos usuários o custo marginal do protocolo incorrido pelas transações. Como a unidade das taxas de transação é a moeda, o mecanismo de taxa envolve a conversão de recursos (por exemplo, etapas da máquina virtual, funções integradas, dados de chamada, gás Ethereum) em tokens (por exemplo, STRK, ETH).
Atualmente, como os provadores cobram taxas com base no total de rastreamentos, e não nas taxas de utilização, os recursos desperdiçados são arcados pelos usuários. O layout dinâmico melhorará a utilização da unidade de rastreamento, reduzindo assim a cobrança de taxas de transação "desnecessárias" (incluindo o consumo de recursos não causado diretamente pelas transações do usuário).
Integração de função interna do Starknet
Neste ponto, a integração de funções incorporadas está aquém da última etapa, que é modificar a base de código Starknet para realizar o uso prático. A extensão da modificação do código está relacionada ao aplicativo de layout e é necessário modificar o código para garantir que o sistema operacional Starknet chame funções integradas quando possível. Por exemplo, o sistema operacional Starknet chama a função hash Poseidon durante a execução do código Cairo e, ao mesmo tempo, chama a função interna Poseidon.
Semelhante aos layouts, os internos do Starknet agora podem ser suportados manualmente. No entanto, ao contrário do caso do layout, esse suporte manual não é uma barreira para a integração, embora existam muitas funções integradas. Em outras palavras, o suporte a builtins do Starknet não é uma barreira para a integração, o layout dinâmico realmente abrirá o caminho para a criação e integração de builtins adicionais.
Resumir
Neste artigo, explicamos o que são funções integradas, seus benefícios, os desafios envolvidos e os planos da StarkWare. O foco atual está no layout dinâmico, que não apenas melhorará a eficiência do processo de prova, mas também facilitará a integração de novos built-ins.