币世王 🦅

自学 AI 实践生 / 明星大使 @ton_blockchain @trondao @Aptos @injective @Solana_zh @ChainbaseHQ @JupiterExchange | 宝藏内容持续输出，建议反操作！

0Ви підписалися

0підписник

Новини

Нещодавно з'явився досить цікавий новий підхід Список дозволів без дозволу в ончейні. Адреса контракту: 0xcb0b0531e86a9ac36fa865ca8e3dbccf047fda91 Названо WhitelistCurator, розбивка основного механізму: 1. Внесіть ETH для заробітку балів, але гроші одразу повертаються. Ви дзвоните депозит() для переказу ETH, і контракт одразу повертає оригінальний спосіб.  Він не з'їдає ваші гроші; він лише фіксує ваші внески і потім оцінює вас. 2. Бали розраховуються не за загальною сумою, а за «приростом». Лише частина, що перевищує вашу попередню максимальну суму депозиту, враховується до балів.  Наприклад, якщо ви вперше внесете 0,1 ETH, ви отримуєте відповідні бали. Наступного разу, коли ви хочете заробити бали, потрібно внести щонайменше 0,2 ETH (збільшити на 0,1).  Постійне заощадження невеликих сум марне; це змушує вас постійно збільшувати свої активи, створюючи справжній «інвестиційний сигнал». 3. Контракт «помре» сам по собі • Перші 24 години — це пільговий період, тож ви можете грати вільно • Після цього ви повинні внести щонайменше 5 ETH на годину, інакше контракт автоматично врегулювається. • Після заморожування білий список фіксується, і нових гравців більше не можна додавати гравців. 4. Заявка дуже проста • Команди проєкту можуть безпосередньо використовувати цей список для створення білого списку або раннього доступу • Коли базується розподіл аїрдропу • Слугує сигналом репутації для онлайн-користувачів «активний + готовий до зростання». Чому це цікаво? Він не вирішує атаки Сібіл, і автор чітко пояснює: після цього можна використати індексатор для очищення офлайн. Але це вирішує ще одну, більш практичну проблему: як швидко сформувати список адрес, які «наразі справді активні та готові продовжувати інвестувати» у чисто ончейн, без дозволу. Більше того, правила абсолютно прозорі, незмінні, а гроші не є опікою — це чистий експеримент «код є правило». Деякі вже бачили обсяги торгівлі понад 1000 ETH, що свідчить про те, що хтось справді грає у гру. // Простіше кажучи: Це генератор білого списку на ланцюгу, який сам відраховує і виживає лише завдяки постійному збільшенню кількості володіння. Чим довше ти живеш, тим ціннішим стає цей список; Якщо ніхто не хоче постійно збільшувати свої інвестиції, це назавжди заморожується. Досить хардкорна маленька іграшка, ідеальна для тих, хто любить механіку на ланцюзі, щоб спробувати. Контракти несуть ризики; подивись сам, я ще досліджую~

Два найкращі скрипти року для мантування NFT — двоє іноземних хлопців: @morsyxbt @Zun2025 Після порівняння немає чіткого переможця (вітаємо обидва); все залежить від вашого сценарію використання • Для публічного карбування — використовуйте morsy • Для обмеженого лиття — використовуйте Zun Моя найкраща порада — поєднувати обидва Функціональні особливості • Швидкість публічного карбування: Morsy швидший, оскільки зчитує дані викликів безпосередньо в ланцюзі, тоді як Zun має запитувати дані у OpenSea перед виходом Однак, якщо він перейде на Rust, реалізація Морсі могла б стати ще компактнішою • Обмежена або за принципом «хто перший прийшов — того й обслуговують»: Morsy не підтримує це, тож перевага у Zun • Архітектура системи: залежить від ваших потреб; однозначної відповіді немає. Архітектура Morsy дуже проста для функцій, які вона виконує - Стан ланцюга> публічні дзвінки > попередньо підписані > розповсюджуються між кількома RPC > карбування Архітектура Zun досить складна - Відкритий пошук даних > роздільної здатності завантаження > Планувальник > валідація транзакцій > підписант > трансляція > карбування • Ефективність під час виконання: Rust швидший за Node, тож Zun тут перемагає. Але не плутати це зі швидкістю — Morsy швидший у відкритому карбуванні • Складність: Морсі легше налаштувати • Ризик: кожен має свої торгові або цінні ризики. - Одна з оптимізацій швидкості для Morsy вимагає попередньо підписаних nonces; якщо гаманець того ж користувача створює іншу транзакцію, ця транзакція стане недійсною - Щодо Zun, це більше довіряє навантаження OpenSea і не оптимізовано для можливості компрометації даних OpenSea Крім того, для делегованого мінтингу, якщо ви не використовуєте одноразовий гаманець, замовлення зберігатиметься, доки ви його не відкликаєте (через CLI або дзвінка)