Динамическое финансирование Chainlink VRF

Question

Я пытаюсь понять, как Chainlink VRF интегрируется в контракты Solidity, например, в этом случайно сгенерированном руководстве по NFT: https://blog.chain.link/random-numbers-nft-erc721/

Мой вопрос касается фактического финансирования оракула. В документах Chainlink VRF отображается это предупреждение: «Запрос случайности завершится неудачно, если в вашем развернутом контракте не будет достаточно LINK для его оплаты. Узнайте, как получить LINK тестовой сети и профинансировать свой контракт». Приведен пример финансирования контракта VRF с помощью метамаска и ремикса.

Однако я не совсем уверен, как это будет работать в больших масштабах. Если у вас есть «фабрика» NFT, которая становится очень популярной с потенциально большим количеством запросов в день / час / минуту, ожидается ли, что вы начнете финансирование этого контракта VRF, чтобы избежать вышеупомянутого предупреждения (похоже, что затраты не будут тривиально / сложно предсказать)?

В качестве альтернативы, если вы хотите, чтобы ваш потребитель NFT финансировал это, вам нужно было бы встроить некоторую логику, которая преобразует эфир в Link, а затем отправляет его в контракт оракула? (или заставить их купить токен ссылки?)

Я мог бы неправильно смотреть на это, но масштабируемость просто не кажется хорошо описанной в документации и рассматривается только с точки зрения тестирования / тестирования сети. Спасибо.

Answer 1

Ты можешь:

1. Перенести расходы прямо на вызывающего абонента

   Требовать LINK оплата или другая форма оплаты, которая покроет расходы на запрос оракула

2. Запрашивайте данные оракула с меньшей частотой (если это позволяет ваш вариант использования)

   Вы получаете информацию о ценах от оракула? Достаточно ли обновлять информацию о ценах один раз в день, а не один раз в час?

3. Измените логику контракта, чтобы не требовать (так много) данных оракула

   Действительно ли вашей фабрике нужна генерация случайных чисел вне сети? Было бы недостаточно для генерации "случайного" числа из хэша блоков, сложности и т. Д.?

Answer 2

мое предложение может быть немного неудобным, но для децентрализации оно может сработать. вы заряжаете свой контракт1 достаточной ссылкой, чтобы начать работу, а затем взимаете с каждого минтера эквивалентную стоимость транзакции ссылки в eth (+%, покрывающий затраты на торговлю по связыванию и передаче между контрактами), и по мере того, как они чеканят, это включено в цену и eth отправляется в контракт 2. во втором контракте просто существует общедоступная вызываемая функция для инициирования обмена для ссылки через routerV2 или аналогичный контракт. путем вызова этой функции и контракта вы можете позволить любому minter активировать функцию контракта свопа, и eth в контракте 2 будет отправлен обратно в контракт 1 в виде ссылки. вы можете использовать счетчик, а затем звонить по контракту 2 каждый раз, когда фонд ссылок заканчивается, и автоматически пополнять его.если вы встроите его в монетный двор, то интер оплачивает сборы.