Перейти к публикации
cp287

Republic Protocol [REN] - децентрализованный даркпул-протокол

Рекомендованные сообщения

CTO REN Loong Wang пришёл в подкаст DARC и поговорил о видении REN в экосистеме, и о том, насколько серьёзно они относятся к конфиденциальности, регулированию и взаимодействию пользователей: 

 

Поделиться сообщением


Ссылка на сообщение

Мартовский апдейт по разработке:

  1. На новом RenEx, децентрализованной бирже от REN, будет упрощённый процесс регистрации новых пользователей;
  2. SwapperD теперь поддерживает Windows, MacOS и Linux. Идёт интеграция с AZTEC (о том что это за зверь читайте в нашем посте);
  3. Запущена новая модель выплат с равномерным распределением платежей для держателей Даркнод.

Источник: чат амбассадоров REN

 

Скрытый текст

 

March Dev Update

  1. New #RenEx is scheduled for release, with a streamlined signup process for new users;
  2. #SwapperD now supports Windows, MacOS, and Linux + AZTEC integration under way;
  3. A new payment model for equal distribution of payments to Darknodes on #RenVM is in progress.

 

Поделиться сообщением


Ссылка на сообщение

CTO REN Loong Wang продолжает своё путешествие по подкастам, и сегодня побывал на Wyre Talks (en): https://simplecast.com/s/e9432194

В этом подкасте Loong поговорил о стратегии REN выхода на рынок, меж-блокчейновом взаимодействии, работе c децентрализованными финансами и внедрении REN в существующие пулы ликвидности. 

 

Поделиться сообщением


Ссылка на сообщение

Был опубликован апрельский (?) отчёт о проделанной работе: https://medium.com/renproject/april-development-update-13a800e6274e

 

RenVM:

  •  был протестирован алгоритм Tendermint с поддержкой сегментированного протокола конфиденциального вычисления (secure multi-party computation), названный Hyperdrive. Количество узлов составляло 1000, блоки создавались в течение нескольких секунд. Ожидается ещё несколько тестов Hyperdrive, после чего начнётся его интеграция в RenVM;
  • был внедрён и протестирован алгоритм цифровой подписи ECDSA. Это огромный шаг вперёд для того, чтобы перемещать токены (читай ценность) между блокчейнами децентрализованным не требующим доверия способом;
  • начали добавлять поддержку JSON-RPC 2.0 в RenVM.

Даркноды:

  • в ближайшее время будет изменена система платежей для даркнод, сделав их более частыми и более справедливыми. Для этого необходимо иметь обновлённую версию даркнод не ниже 2.2.9.

SwapperD:

  • SwapperD теперь поддерживает атомарные свопы с ZCash.

И небольшой Q&A от Loong Wang в чате амбассадоров:

Скрытый текст

Loong:
This month was a big one for us. I can’t highlight enough how awesome it was to get ECDSA key pairs working inside RenVM. Interactive demos for everyone are on the horizon!

Exciting stuff! Thanks for update. Any timeline on the release of additional details pertaining to the new payment system?
Soon, we are just wrapping up the final bits of dev and then it will undergo review and integration into the system. Review is very important to get done perfectly so we are hesitant to give exact times.

Did you mean interoperability between different blockchains (say BTC/ZEC) or between different exchanges?

Between different blockchains, but with a focus on DEXs to begin with. Demos will come out so people can see exactly what we mean (a web app is worth a thousand pages of docs).

Is there a specific use case being targeted for renvm you can share.  will it enhance the dark pool offering ina way that will make it more compelling or are there other areas you are looking at tackling with it?

Truly trustless and decentralised interoperability was a problem that we needed to solve when tackling dark pools exclusively. But, we very quickly realised this problem is not exclusive to dark pools. Almost every dApp on Ethereum right now could benefit from this too. So to maximise the value that Ren brings to the world, and at the same time maximise the utility of Darknodes (means more revenue means more Darknodes means more security) we are making this interoperability layer completely general. Starting with trading, because it’s such a proven use case.

Having a "hook" though really helps, something specific to offer and prove it works.  Im sure youll have something as it approaches launch.  The dark pool solutions was great and easy to communicate, so having something like that for renvm to start would be great. Very excited to see it progress and amazed to see how the scope has broadened since finding the project a little over a year ago.
A good point, and we’re definitely aware that having a clean vertical makes a world of difference to messaging. We’ll have some concrete demonstrations of how this tech can be applied, and to highlight its key use cases.

Great, i think ive tried pretty much every dex on ethereum so happy to help talk through use cases/pain points.
We’ll definitely take everyone up on these offers soon! We’re in comms with many projects to make sure things are as plug-and-play as possible. A lot of focus going into the UX. Our progress at the moment is showing that it should be possible, in a single transaction, for a user to sell BTC for ZEC (again just examples) on an Ethereum DEX without the user doing anything other than specifying their addresses and making a normal BTC transfer.
 

 

Поделиться сообщением


Ссылка на сообщение

REN расписал почему RenVM будет важна для децентрализованных финансов, и привёл список того, на чём в данный момент сосредоточена команда (en): https://medium.com/renproject/rens-future-in-defi-d34ffd903192

 

В данный момент продолжая строить REN мы сосредоточены на:

  • завершении исследования новой экономической модели токена и начало ее реализации;

  • внедрение консенсусных механизмов Hyperdrive в Tendermint для координации даркнод;

  • создание уровня межблокчейнового взаимодействия и запуск первого комплексного решения для децентрализованных приложений RenShift;

  • улучшение безопасности и производительности RenVM;

  • набор инструментов для взаимодействия с RenVM;

  • язык сценариев, созданный для RenVM.

Поделиться сообщением


Ссылка на сообщение

CTO REN Loong Wang показал в твиттере, как они с помощью sMPC-алгоритма без доверия и централизованной силы перевели биткоин в сеть эфериума. Пока в тестовых версиях. Вот это ребята работают, я понимаю.

 

Поделиться сообщением


Ссылка на сообщение

Ren изменил систему вознаграждений darknode: теперь награды будут распределяться в конце каждого цикла (примерно раз в месяц), и будут равномерно распределены между всеми darknode'ами, которые активно участвовали в течение этого месяца. Ранее система награждала за работу ноды в порядке очереди, что приводило иногда не к равномерному распределению вознаграждений в зависимости от обработанных обменных транзакций.

Также была добавлена дополнительная награда даркнодам за обслуживание транзакций, которые не имеют денежной оценки (оказание различных операций через RenVM). Такие транзакции будут оплачиваться в DAI из расчёта 0.000005 DAI/сек или 0.0000002 DAI/байт.

Поделиться сообщением


Ссылка на сообщение

В настоящий момент поддерживаются 4 типа наград: BTC, ZEC, DAI, ETH.
Darknodes начали тратить ETH, в качестве GAS'a, для автоматического вызова процедуры перечисления заработанных токенов на ноду. Сейчас это происходит в среднем раз в 24 час, в результате чего ETH тратится регулярно. В ближайшее время произойдут изменения и эта процедура будет происходить раз в 4 недели. Если нода находится в офлайне в течении длительного времени - сутки и более, другие ноды добавят не активную ноду в блэклист.

Награды начисляются регулярно, но маленькими суммами.

Поделиться сообщением


Ссылка на сообщение

Сегодня автоматический вызов цикла перевода наград стал 7 дней. Это позволит экономить GAS на балансе узла, который необходим еще и для защиты сети Темных узлов, если какой-то темный узел будет злонамеренно модифицирован, другие узлы смогут это обнаружить, но чтобы подтвердить и проверить злонамеренное поведение, узлам необходим GAS. Нода которая первой подтвердит вредоносный узел, получает 50% застеканных токенов (50к REN), остальные 50% - сгорают. 

Стоит отметить, что не смотря на отсутствие маркетинговых усилий от команды проекта, REN был одним из первых токенов, на который Delphi Digital сделали подробное исследование для институциональных подписчиков.
Binance выпустили отчет о токене, так же проект попал в систему рейтингов Binance
 

053f0590-82a2-457a-a364-282c3e89a881.jpg

Поделиться сообщением


Ссылка на сообщение
14.01.2019 в 02:08, cp287 сказал:

Установил себе dark node через DigitalOcean . Это была с запасом самая простая в установке нода.

Судя по сообщениям в чате она пока будет работать в минус, но как можно работать в минус, если у тебя 100$ бесплатные в Digital Ocean, а больше ни за что платить не надо :hug:?

Как наберу статистику по выплатам (наверное через месяц), то обязательно сообщу итоги.

 

добрый день, появилось понимание касательно рентабельности держания ноды?

Поделиться сообщением


Ссылка на сообщение
3 часа назад, 1n5734d0fu сказал:

добрый день, появилось понимание касательно рентабельности держания ноды?

В данный момент все еще идет условный период ограниченного участия.
Ноды не являются рентабельными, но все-таки финансовое бремя сильно снизилось 🙂 Рекомендуемый размер сервера стал стоить $5 для DO и ~$7,5 для AWS, так же уменьшилось количество активных узлов с ~250 до ~160 - всё это помогает снижать издержки. Думаю, что пока не появятся сторонние приложения - ноды не будут рентабельными. Награды, что есть сейчас - награды от тестирования приложений.

Выплаты можно посмотреть здесь: https://rentracker.io/ 
Но в эти выплаты не входят некоторые награды, т.к. трекер показывает что последние выплаты были 2 мая, а многое ноды получили награды в ETH и DAI за последние две недели.

Изменено пользователем antaeus

Поделиться сообщением


Ссылка на сообщение

Скрин с моими наградами, нужно поделить на 2, т.к. у меня запущено 2 узла.

2019-05-17_17-07-45.png

Поделиться сообщением


Ссылка на сообщение

Был опубликован майский отчёт о проделанной работе https://medium.com/renproject/may-development-update-aa000697ec4e

RenVM:

  • Реализован слой совместимости, с демонстрацией обмена DAI/BTC, используя Ethereum DEX
  • Hyperdrive (алгоритм консенсуса, который используют Даркноды, на основе модифицированного алгоритма Tendermint/Cosmos) ,был интегрирован в RenVM в Devnet, протестирован на 1000 узлов.
  • JSON-RPC 2.0 добавлен в Devnet, сервис необходимый сторонним разработчикам, для создания приложений

Darknodes:

  • Новая модель наград 
  • Уменьшение требований к ресурсам узла (писал выше)

Lightnodes:

  • Lightnodes - шлюз имитирующий интерфейс JSON-RPC 2.0, для создания веб приложений. Добавлено в Devnet

 

В Q2 обещали инструменты для сторонних разработчиков и похоже пока все идет по плану. Пишут что отдать инструменты для разрабов - ближайшая цель.

Поделиться сообщением


Ссылка на сообщение
5 часов назад, 1n5734d0fu сказал:

добрый день, появилось понимание касательно рентабельности держания ноды?

Сорри, забыл подбить статистику.

Как уже ответил @antaeus, содержание ноды пока не рентабельно, хотя и стало значительно лучше. Подбивая цифры: за 4 месяца я заплатил за хостинг 83$, получил с наград ноды на 24$, т.е. я потерял 59$ на содержание ноды.

Но сейчас действительно ситуация стала лучше, так как хостинг стоит всего 5$, и ноды близки к тому, чтобы быть хотя бы окупаемыми

Поделиться сообщением


Ссылка на сообщение

Опубликовали FAQ за май.   В мае и апреле, многие просили команду делать AMO - бизнес сессии, где обсуждается именно бизнес стратегия проекта, чтобы инвесторам было спокойнее. Но в регулярных месячных FAQ - есть ответы на многие вопросы, в т.ч. относительно бизнес модели, а не только технического прогресса.
В майском FAQ - чем RenVM отличается от Cosmos/Polkadot/AION и прочих, выход инструментов для разработки сторонних приложений, риски от создания форков, динамическую модель вознаграждений и выбор токена DAI для комиссий и многое другого интересного.

Поделиться сообщением


Ссылка на сообщение
3 часа назад, antaeus сказал:

Опубликовали FAQ за май.   В мае и апреле, многие просили команду делать AMO - бизнес сессии, где обсуждается именно бизнес стратегия проекта, чтобы инвесторам было спокойнее. Но в регулярных месячных FAQ - есть ответы на многие вопросы, в т.ч. относительно бизнес модели, а не только технического прогресса.
В майском FAQ - чем RenVM отличается от Cosmos/Polkadot/AION и прочих, выход инструментов для разработки сторонних приложений, риски от создания форков, динамическую модель вознаграждений и выбор токена DAI для комиссий и многое другого интересного.

На всякий случай скопирую этот FAQ, так как такие тексты имеют свойство пропадать с сайтов разработчиков через какое-то время, а текст действительно большой, интересный и отвечает на много хороших вопросов:

Скрытый текст

Best General RenVM Questions of May


 

Q: Is RenVM in competition with Cosmos/Polkadot/Aion, etc.?

A: No, we're actually big fans of these protocols and RenVM complements them quite nicely, as it can serve as ‘pegged zones’ and bring an elegant solution to the legacy blockchain integration issue they face. 

In general, RenVM is bringing interoperability to Ethereum and the world of DeFi instead of asking DeFi projects to come build on their respective smart-contract protocol. Another way of saying it is, most current interop projects are creating a protocol standard and bringing other (new) blockchains into that standard. RenVM takes the other approach and brings itself to others (new and existing) blockchains.

For a more in-depth understanding of how RenVM work we encourage individuals to listen to this podcast: https://podcasts.apple.com/au/podcast/hashing-it-out-46-ren-loong-wang/id1376906132?i=1000439188131

 

Q: So is it right to think of RenVM as tackling some of the same problems a project like Aion is trying to solve? But in RenVM's take we have the advantage of privacy built in to the protocol?

A: The advantage of privacy is one aspect. The biggest aspect is that RenVM works with existing blockchains. We don’t have to wait for blockchains to implement our standard, instead, we can hook into them straight away. Furthermore, control is distributed to hundreds if not thousands of nodes instead of other naive solutions which are limited to 20 (and that’s not really decentralized)

Where RenVM wins out over other sMPC is that we have developed a new technique that makes the kinds of elliptic curve crypto that you need efficient and scalable and (most importantly) it works even if up to 1/3rd of the nodes try to abort the computation. All other solutions out there right now will fail if even a single node goes offline.

So not only is our solution the only one that is fast enough to be usable with a large number of nodes, it’s also the only one that can survive the kinds of faults that you would expect to see in a decentralized and Byzantine environment.

 

Q: How is Ren’s Interoperability solution different to that of WBTC?

A: The Ren interoperability solution is a standalone initiative developed in-house by the Ren team. It is a separate solution to that of WBTC.

WBTC utilizes a centralized custodian model. BitGo serves as the authority which mints and burns BTC to create WBTC and then distributes it via a set of Merchant's (ie. exchanges) to disseminate (RenEx being one of them). However, only BitGo has the ability to mint and burn. It is, therefore, a centralized, permissioned custodial model for wrapping BTC and bringing it into the DeFi Ecosystem.

RenVM’s removes the need for a centralized custodian, which mean anyone or any DeFi app can mint and burn BTC or any other digital asset, seamlessly. This allows DeFi applications to plug the RenVM solution into their existing smart contract infrastructure, which allows individuals to send real BTC, etc. to DeFi application; users never have to worry about minting or burning when interacting with a dApp. It is, therefore, a permissionless, trustless, system which allows for fluid movement of cross chain assets in and out of the DeFi ecosystem (ie. interoperability).

With this said, the WBTC model can utilize our decentralized custodian model, to mint and burn WBTC if they choose to allow a permissionless custodianship of WBTC. We will not show favoritism or preference, as our solution is permissionless, anyone who would like to utilize our interoperability capabilities, can do so. We helped build, and continue to support, the WBTC initiative because it allows the adoption of BTC on Ethereum today. As the ecosystem grows, we will, of course, see many different types of solutions for different use cases. Some people like, or even require, custodians and WBTC will continue to serve this part of the market. RenVM will open the way for truly permissionless and decentralized interoperability.

 

Q: How would RenVM compliment something like the Decred Atomic Swap exchange? Would it essentially become another aggregated order book that would interact with RenEx?

Atomic swaps demonstrate that exchange intermediaries are unnecessary, so it is natural to remove them. The server will only assist in the price discovery and order matching process, and it will be entirely non-custodial.

RenVM is a natural replacement for Atomic Swaps wherever they are being used. Its decentralized nature means that it is not introducing “intermediaries” that can interfere with the process. Interop using RenVM is faster than atomic swaps, it is non-interactive (parties do not have to be online all the time and cancelation cannot happen), and it is compatible with all wallets (no special software is needed by the user).

 

Q: Fee Model: So in summary, we get a percentage of what moves through RenVM and DAI if it's not a normal trade?

A: That is essentially correct (w/ some nuance); check out our fee model overview for more detailed information:https://medium.com/renproject/a-new-fee-model-for-ren-63f9c3273bec

 

Q: Can you explain the new fee model’s intent? 

A: The focus of the changes to the fee model are two-fold:

First, the new contract ensures even distribution of fees to all actively participating Darknodes more consistently (instead of having to wait a month for a larger payment, everyone should see more frequent smaller payments). This comes as a direct result from feedback from all those that have been running Darknodes.

Secondly, to make it possible for more varied applications to utilize RenVM. To access its interoperable liquidity layer, but also to prepare for the general purpose scripting capabilities. This widens the use cases for RenVM drastically, increasing the avenues for fees to flow to RenVM (this supports more Darknodes which makes the system more secure which makes it able to handle more liquidity and the positive feedback cycle goes on). It comes at the disadvantage of not being as customized for the specific use case that is dark pools.

 

Q: The reason for choosing DAI seems based on the fact that is decentralized and that team is betting in its adoption, what is the plan if that adoption doesn’t occur. How the network can be affected if that adoption does not occur?

A: Governance is a tricky topic and not one that we have seen a reasonable solution to yet. But, if Dai fails to remain viable then we will change as needed. If there isn’t another decentralized stablecoin available at that time, there are other options (such as letting people pay in anything and just let the Darknodes make up their minds about what is acceptable; obviously lots of kinks that would need to be worked out but nothing that can’t be managed).

 

Q: Why did you use DAI instead of REN for the upfront payment to darknodes?

A: In addition to the points raised in our recent blog, this approach brings greater external value and therefore security to the network; instead of creating a circular value system where Darknodes need REN, to earn REN. REN could easily be used as the payment token along with its use as a staking mechanism. However if this was done, it would greatly increase the token velocity, which limits the scope of potential value capture of REN.

Referring to Kyle Samani’s report from Multicoin Capital on New Models For Utility Tokens, by using another token for payments, REN becomes what Samani describes as a ‘work’ token, similar in function to other tokens such as REP. With a work token increased usage of the network will cause an increase in the price of the token. As demand for the service grows, more revenue will flow to service providers. Given a fixed supply of tokens, service providers will rationally pay more per token for the right to earn part of a growing cash flow stream.” That is, the valuation can be estimated using a net present value (NPV) model (a multiple of the system cash flows).

This is in contrast to payment tokens (tokens used as money) such as Filecoin that are valued as a fraction of the revenue paid to the service providers. To explore this concept further, we encourage you to read Samani’s report if seeking to understand the thinking behind our design choices.

 

Q: 0.1% seems high and may incentivize forks. Maybe start with 0.01% and increment later (proportional to how much liquidity comes in). Liquidity is the strongest moat, needs to be bootstrapped well (recall how the 0.5% interest in MakerDao resulted in explosive growth in Dai (to long eth))

A: This is ultimately subject to what the Darknodes choose to accept. But, bootstrapping has to start somewhere and it has to start at a level where lower volumes (as the platform is adopted) can support a baseline number of Darknodes for security. It’s a bit of a chicken and egg problem, and we are approaching it by starting with higher fees than we anticipate long term.

Without a reasonable number of Darknodes, there isn’t enough security, so there would not likely be serious volume. On the flip side, once there is serious volume then lower fees are enough to sustain a reasonable number of Darknodes.

 

Q: Should/can Ren itself run nodes + subsidize initially to solve the chicken/egg problem? Maybe the smaller users/dApps can be spared fee at least initially? It is a fact that small fish won't pay for privacy, they just don't care. OTOH having such low-value tx's through the network increases legitimacy and trust for the big fish?

A: A smaller cut of larger amounts is definitely preferable. But larger amounts will not be safe to use with a low number of Darknodes. We will be running Darknodes ourselves once the interop layer is available, and there is a very specific rollout plan to help drive Darknode numbers to a secure and sustainable level whilst also adopting volume.

 

Q: It sounds like traders in a dynamic fee dark pool can pay fees in the tokens they're moving, which is great for them. But for Darknodes, that means fees will pay out in volatile assets just once per month. What are the arguments against swapping the dynamic fees for Dai? Sounds like a disconnect between the dynamic fee and much of what Tai discussed in his Medium about volatility.

A: It’s true that volatility is an issue for the dynamic fees. But the tradeoff in terms of (a) smooth user experience, (b) volume based payments even when volumes are private, and (c) not having to separate payment from work done is absolutely worth it. Darknodes will also ultimately be deciding what they’re accepting into the interoperable liquidity layer.

 

Q: Interoperability will come with a significant premium for traders then, in the order of tens/hundreds of thousands of dollars per block trade (relative to using a dark pool with decentralized matching and centralized settlement for pennies). You mentioned in the Wyre podcast that you've gotten feedback from desks. Have they indicated a willingness to pay in the order of a 10,000x+ private settlement premium?

A: A hypothetical dark pool would not be offering their services for free. They would be charging their own % either way (and this is typically higher than 0.1%).

RenVM is aimed at decentralized use cases. Decentralized dark pools, DEXs, DeFi apps etc. that what to charge X% can instead charge X-0.1% or if they don’t want to absorb the cost then the trader has an extra 0.1% fees (which I’ll touch on in a moment). The alternative is trusting a centralized settlement layer with your funds (and as we’ve just seen yesterday with the $40M+ Binance hack, this isn’t a good idea). It’s not just about the privacy of the settlement. It’s about the trustless nature of the settlement, removing counterparty risk, and being able to store your funds where you deem to be appropriate.

The 0.1% is a starting point to bootstrap things (and is subject to change). Before large volumes can be safely transacted we need lots of Darknodes which means we need lots of fees. In this initial phase, the volume will be lower and so fees need to be higher to sustain Darknode numbers. As volume grows, the fee can be reduced without resulting in the loss of Darknodes.

 

Q: Can a centralized dark pool using the matching engine then get away with paying pennies in fees for block trades?

A: It will pay for the work it consumes. The challenge is that allowing general-purpose scripting means that “forcing” dark pools to pay per volume at the order matching level is impossible. They could just defer to the general purpose scripting level and write the same functionality there.

If settlement was being done on RenVM, as oppose to order matching (or in addition to it), then the interoperable liquidity features of RenVM are being engaged which requires special instructions that cannot be built using general purpose scripting (in theory you could build them but they are so wildly inefficient that it’s not reasonable to use general purpose scripting in this way).

As it stands, the only known way to do private interoperable trades in a way that is decentralized, trustless, and unable to be canceled by either party (the precise needs of a decentralized dark pool but also a wide range of other financial applications) is to use something like secure multiparty computation and RenVM is the only solution that is efficient enough at curve cryptography to actually make this usable in practice.

 

Q: What would be the recommended fee model for a dark pool with non-monetary assets? For example, consider an exchange between two token identifiers representing shares in a prediction market.

A: Whatever the computations/data required to do that exchange are would dictate the minimum fee. Increasing that can be used to prioritize the work over other work.

 

Q: Requiring an upfront fee for limit orders isn't great UX. At the dark pool layer, why not return the fee for canceled orders? Is that different from a trader spamming the network with unrealistic orders using a dynamic fee?

A: This would allow people to attack the virtual machine by getting it do work that it isn’t being paid for. When using dynamic fees, the fee is an intrinsic part of the computation. With Dai fees, one has to come before the other and doing the compute first would allow an attack scenario where you request a heavy computation and then don’t pay for it.

 

Q: Hence my last question: how does that scenario differ from a trader spamming/pinging the network with orders that will never be filled in a dark pool using dynamic fees?

A: Because dynamic fees are only available for the movement of tokens. Order matching (the stage that comes before settlement and thus movement of tokens) is not in itself the movement of tokens and so requires Dai fees.

 

Q: Say for an unfillable limit order, is it in the realm of cents? Fractions of a cent?

A: That’s about what I’d expect. Just under 1c depending on the number of orders on the book (and we will continue to push that lower as we reduce the hardware requirements of Darknodes). Still 50-100x improvement over Ethereum in regards to cost and speed

 

Q: Then can a trader could just spam the venue?

A: The venue can implement its own spam protection. RenVM itself is permissionless so it can only use economic incentives to protect itself. Applications can apply their kinds of context-specific restrictions (KYC is an example of such a restriction, albeit not one around spamming)

 

Q: You say here that everyone should see more frequent smaller payments, but in the blog, it says payments will be once per month. Which one is correct?

A: Both are correct. Fees will be allocated to Darknodes more frequently (and this will be reflected in the DCC) but Darknodes will only be able to claim these fees at the end of each payment cycle.

 

Q: For example, theoretically if 4 weeks cycle starts 15th may all darknode which were registered will earn fees but if somebody registers a node 16th may his node will be off and he will be waiting half a month to earn fees, correct?

A: If you are not already registered and whitelisted before a cycle begins you will not earn fees in that cycle. The optimal behavior is register and whitelist on the last day of a cycle.

 

Q: What date new cycle will start?

A: Cycles are currently set to be 7 days in length so that Darknodes that are already registered are able to get whitelisted quickly. Soon we will move to 4 week period but certainly, let the community know when we make that switch via a formal announcement.

 

Q: If I deregister my Darknode with Pending Fees in my DCC will I lose them?

A: Yes, The safest thing to assume: if you haven’t withdrawn the fees when you deregister then you will not get those fees if you deregister. It says “Claim again in 11 hours”. At the moment, the cycles are set to only one day, to ensure time for all Darknodes to correctly adjust to the new contract. But, a cycle will usually be 4 weeks. See the messages above about why.

 

Q: Do we have to manually claim pending fees to move them to withdrawable?

A: You can manually claim fees to move them to withdrawable. But your Darknode will do it automatically for you (assuming it has enough gas)

 

Q: Are the cycles ‘prorated’ so to speak? As I understand, a node needs to be active for the entire cycle in order to receive rewards? Does that mean if I deactivate a node after a cycle begins to downgrade my vps I am ineligible for rewards from that entire cycle?

A: Yes, this is done for three reasons.

The first is that you get a better $ per month overall by only having to claim your fees once per month (claiming requires gas, therefore costs a bit of money, a couple cents per month is okay but every day or even every payment is looking worse).

The second is that it enables a more even distribution of the fees over the course of the whole month.

The third, and the most important is that it forces stability. The security and liveliness of the network depend on people keeping their Darknodes running (this is just as important as having people running nodes). Having to wait a month is an economic incentive to maintain the Darknode for the whole month. Your hardware expenses are billed once a month and salaries are typically quoted once per month so this is the reason for the particular choice of four weeks (whole weeks are nice and it’s just under the one month cadence).

If you fail to maintain the Darknode sufficiently during a cycle the Darknode will not earn fees ever again (you will need to deregister and register a new one). In the latest version of the Darknode CLI there is now a command that will resize the hardware for you without causing much downtime (or needing to deregister and reregister).

 

Q: Are you still planning to Release 3rd Party tool for Darkpools in Q2? 

A: We are aiming to put out dev tools but not for third-party dark pools. We will be releasing them for third-parties to use the interoperable features of RenVM as this is the more general feature. Simply said, cross-chain interop needs to come first, otherwise dark pools won’t be that useful.

 

Q: Wrt decentralized dark pools, I think you mentioned that RenEx is no longer being pursued as a formal product.
1) I know it's a "demo," but is it being deprecated? What should we expect from it going forward?

2) There are no other decentralized dark pools yet. Are you expecting most dark pool volume to come from new, upstart dark pools not built yet or existing dex's planning to add dark pool functionality?

A: As RenVM progresses and the interop layer makes its way to Mainnet, RenEx will be upgraded to make use of these new features (and by extension pay these new fees). We expect volume to come from some new applications being built by other teams and from integration into existing DEXs / DeFi.

 

Q: You seemed to insinuate yesterday that a prediction market dark pool should use the Dai fee model rather than the dynamic fee model.

Assume an Augur market with YES and NO shares, where shares are represented by ERC777 tokens. They don't have an explicit monetary value outside of the Augur contracts. If a trade is made with these shares, then rather than Darknode operators manually having to cash in these shares for Dai on Augur, could there not be a RenVM<>Augur swapper that swapped the shares for Dai? Thereby making the dynamic fee possible for these assets? Darknode operators may be left with an assortment of YES and NO shares from various markets that are worthless unless they're redeemed for Dai in Augur. My question is: other than a  RenVM<>Augur swapper, what would prevent a dark pool from using the dynamic fee model?

A: The settlement layer for RenVM only really comes into play for cross-chain settlements. In the case of Augur <> Dai this would just settle on-chain, unless you had explicitly built a script into RenVM to manage this secretly. In this case the movement of the fungible token would require dynamic fees but the movement of the NFT wouldn’t.

The biggest challenge is finding a way to express these fees in a way that is generalizable. We don’t want to embed a whole bunch of specific cases into the protocol. All these scenarios are subtly different and it is better to have one or two rules that captures most use cases optimally and some use cases sub-optimally than to have an indeterminate number of rules (every time someone builds an application we would be asking ourselves “how do we modify the fee rules to accommodate this?”)

I could imagine a way whereby Ren requires Dai fees to be dynamic by “estimating” the equivalent price of NFTs moves (i.e. transferring an NFT of equivalent value of $X would require X*0.001 Dai). But even this is specific to the use case of NFTs.

 

Q: will you be able to run a Lightnode client side, in the browser?

A: Not in the browser. The intent is that Lightnodes will be what the browser interacts with. The nature of SSL prevents Darknodes being able to be accessed directly by browsers (most block https => http content) because Darknode do not have their own domains and therefore cannot have SSL certs (and even if they could this requires a centralized authority to provide it). Lightnodes alleviate this by allowing developers to deploy them behind their application domain so that the browser can communicate with it over SSL, and then it can communicate with the Darknodes.

 

Лично я, прочитав этот FAQ, решил, что докуплю ещё одну Тёмную ноду в ближайшем будущем.

Поделиться сообщением


Ссылка на сообщение
11 часов назад, antaeus сказал:

Опубликовали FAQ за май.   В мае и апреле, многие просили команду делать AMO - бизнес сессии

*AMA, не AMO.
 

9 часов назад, cp287 сказал:

На всякий случай скопирую этот FAQ, так как такие тексты имеют свойство пропадать с сайтов разработчиков через какое-то время, а текст действительно большой, интересный и отвечает на много хороших вопросов:

  Показать содержимое

Best General RenVM Questions of May


 

Q: Is RenVM in competition with Cosmos/Polkadot/Aion, etc.?

A: No, we're actually big fans of these protocols and RenVM complements them quite nicely, as it can serve as ‘pegged zones’ and bring an elegant solution to the legacy blockchain integration issue they face. 

In general, RenVM is bringing interoperability to Ethereum and the world of DeFi instead of asking DeFi projects to come build on their respective smart-contract protocol. Another way of saying it is, most current interop projects are creating a protocol standard and bringing other (new) blockchains into that standard. RenVM takes the other approach and brings itself to others (new and existing) blockchains.

For a more in-depth understanding of how RenVM work we encourage individuals to listen to this podcast: https://podcasts.apple.com/au/podcast/hashing-it-out-46-ren-loong-wang/id1376906132?i=1000439188131

 

Q: So is it right to think of RenVM as tackling some of the same problems a project like Aion is trying to solve? But in RenVM's take we have the advantage of privacy built in to the protocol?

A: The advantage of privacy is one aspect. The biggest aspect is that RenVM works with existing blockchains. We don’t have to wait for blockchains to implement our standard, instead, we can hook into them straight away. Furthermore, control is distributed to hundreds if not thousands of nodes instead of other naive solutions which are limited to 20 (and that’s not really decentralized)

Where RenVM wins out over other sMPC is that we have developed a new technique that makes the kinds of elliptic curve crypto that you need efficient and scalable and (most importantly) it works even if up to 1/3rd of the nodes try to abort the computation. All other solutions out there right now will fail if even a single node goes offline.

So not only is our solution the only one that is fast enough to be usable with a large number of nodes, it’s also the only one that can survive the kinds of faults that you would expect to see in a decentralized and Byzantine environment.

 

Q: How is Ren’s Interoperability solution different to that of WBTC?

A: The Ren interoperability solution is a standalone initiative developed in-house by the Ren team. It is a separate solution to that of WBTC.

WBTC utilizes a centralized custodian model. BitGo serves as the authority which mints and burns BTC to create WBTC and then distributes it via a set of Merchant's (ie. exchanges) to disseminate (RenEx being one of them). However, only BitGo has the ability to mint and burn. It is, therefore, a centralized, permissioned custodial model for wrapping BTC and bringing it into the DeFi Ecosystem.

RenVM’s removes the need for a centralized custodian, which mean anyone or any DeFi app can mint and burn BTC or any other digital asset, seamlessly. This allows DeFi applications to plug the RenVM solution into their existing smart contract infrastructure, which allows individuals to send real BTC, etc. to DeFi application; users never have to worry about minting or burning when interacting with a dApp. It is, therefore, a permissionless, trustless, system which allows for fluid movement of cross chain assets in and out of the DeFi ecosystem (ie. interoperability).

With this said, the WBTC model can utilize our decentralized custodian model, to mint and burn WBTC if they choose to allow a permissionless custodianship of WBTC. We will not show favoritism or preference, as our solution is permissionless, anyone who would like to utilize our interoperability capabilities, can do so. We helped build, and continue to support, the WBTC initiative because it allows the adoption of BTC on Ethereum today. As the ecosystem grows, we will, of course, see many different types of solutions for different use cases. Some people like, or even require, custodians and WBTC will continue to serve this part of the market. RenVM will open the way for truly permissionless and decentralized interoperability.

 

Q: How would RenVM compliment something like the Decred Atomic Swap exchange? Would it essentially become another aggregated order book that would interact with RenEx?

Atomic swaps demonstrate that exchange intermediaries are unnecessary, so it is natural to remove them. The server will only assist in the price discovery and order matching process, and it will be entirely non-custodial.

RenVM is a natural replacement for Atomic Swaps wherever they are being used. Its decentralized nature means that it is not introducing “intermediaries” that can interfere with the process. Interop using RenVM is faster than atomic swaps, it is non-interactive (parties do not have to be online all the time and cancelation cannot happen), and it is compatible with all wallets (no special software is needed by the user).

 

Q: Fee Model: So in summary, we get a percentage of what moves through RenVM and DAI if it's not a normal trade?

A: That is essentially correct (w/ some nuance); check out our fee model overview for more detailed information:https://medium.com/renproject/a-new-fee-model-for-ren-63f9c3273bec

 

Q: Can you explain the new fee model’s intent? 

A: The focus of the changes to the fee model are two-fold:

First, the new contract ensures even distribution of fees to all actively participating Darknodes more consistently (instead of having to wait a month for a larger payment, everyone should see more frequent smaller payments). This comes as a direct result from feedback from all those that have been running Darknodes.

Secondly, to make it possible for more varied applications to utilize RenVM. To access its interoperable liquidity layer, but also to prepare for the general purpose scripting capabilities. This widens the use cases for RenVM drastically, increasing the avenues for fees to flow to RenVM (this supports more Darknodes which makes the system more secure which makes it able to handle more liquidity and the positive feedback cycle goes on). It comes at the disadvantage of not being as customized for the specific use case that is dark pools.

 

Q: The reason for choosing DAI seems based on the fact that is decentralized and that team is betting in its adoption, what is the plan if that adoption doesn’t occur. How the network can be affected if that adoption does not occur?

A: Governance is a tricky topic and not one that we have seen a reasonable solution to yet. But, if Dai fails to remain viable then we will change as needed. If there isn’t another decentralized stablecoin available at that time, there are other options (such as letting people pay in anything and just let the Darknodes make up their minds about what is acceptable; obviously lots of kinks that would need to be worked out but nothing that can’t be managed).

 

Q: Why did you use DAI instead of REN for the upfront payment to darknodes?

A: In addition to the points raised in our recent blog, this approach brings greater external value and therefore security to the network; instead of creating a circular value system where Darknodes need REN, to earn REN. REN could easily be used as the payment token along with its use as a staking mechanism. However if this was done, it would greatly increase the token velocity, which limits the scope of potential value capture of REN.

Referring to Kyle Samani’s report from Multicoin Capital on New Models For Utility Tokens, by using another token for payments, REN becomes what Samani describes as a ‘work’ token, similar in function to other tokens such as REP. With a work token increased usage of the network will cause an increase in the price of the token. As demand for the service grows, more revenue will flow to service providers. Given a fixed supply of tokens, service providers will rationally pay more per token for the right to earn part of a growing cash flow stream.” That is, the valuation can be estimated using a net present value (NPV) model (a multiple of the system cash flows).

This is in contrast to payment tokens (tokens used as money) such as Filecoin that are valued as a fraction of the revenue paid to the service providers. To explore this concept further, we encourage you to read Samani’s report if seeking to understand the thinking behind our design choices.

 

Q: 0.1% seems high and may incentivize forks. Maybe start with 0.01% and increment later (proportional to how much liquidity comes in). Liquidity is the strongest moat, needs to be bootstrapped well (recall how the 0.5% interest in MakerDao resulted in explosive growth in Dai (to long eth))

A: This is ultimately subject to what the Darknodes choose to accept. But, bootstrapping has to start somewhere and it has to start at a level where lower volumes (as the platform is adopted) can support a baseline number of Darknodes for security. It’s a bit of a chicken and egg problem, and we are approaching it by starting with higher fees than we anticipate long term.

Without a reasonable number of Darknodes, there isn’t enough security, so there would not likely be serious volume. On the flip side, once there is serious volume then lower fees are enough to sustain a reasonable number of Darknodes.

 

Q: Should/can Ren itself run nodes + subsidize initially to solve the chicken/egg problem? Maybe the smaller users/dApps can be spared fee at least initially? It is a fact that small fish won't pay for privacy, they just don't care. OTOH having such low-value tx's through the network increases legitimacy and trust for the big fish?

A: A smaller cut of larger amounts is definitely preferable. But larger amounts will not be safe to use with a low number of Darknodes. We will be running Darknodes ourselves once the interop layer is available, and there is a very specific rollout plan to help drive Darknode numbers to a secure and sustainable level whilst also adopting volume.

 

Q: It sounds like traders in a dynamic fee dark pool can pay fees in the tokens they're moving, which is great for them. But for Darknodes, that means fees will pay out in volatile assets just once per month. What are the arguments against swapping the dynamic fees for Dai? Sounds like a disconnect between the dynamic fee and much of what Tai discussed in his Medium about volatility.

A: It’s true that volatility is an issue for the dynamic fees. But the tradeoff in terms of (a) smooth user experience, (b) volume based payments even when volumes are private, and (c) not having to separate payment from work done is absolutely worth it. Darknodes will also ultimately be deciding what they’re accepting into the interoperable liquidity layer.

 

Q: Interoperability will come with a significant premium for traders then, in the order of tens/hundreds of thousands of dollars per block trade (relative to using a dark pool with decentralized matching and centralized settlement for pennies). You mentioned in the Wyre podcast that you've gotten feedback from desks. Have they indicated a willingness to pay in the order of a 10,000x+ private settlement premium?

A: A hypothetical dark pool would not be offering their services for free. They would be charging their own % either way (and this is typically higher than 0.1%).

RenVM is aimed at decentralized use cases. Decentralized dark pools, DEXs, DeFi apps etc. that what to charge X% can instead charge X-0.1% or if they don’t want to absorb the cost then the trader has an extra 0.1% fees (which I’ll touch on in a moment). The alternative is trusting a centralized settlement layer with your funds (and as we’ve just seen yesterday with the $40M+ Binance hack, this isn’t a good idea). It’s not just about the privacy of the settlement. It’s about the trustless nature of the settlement, removing counterparty risk, and being able to store your funds where you deem to be appropriate.

The 0.1% is a starting point to bootstrap things (and is subject to change). Before large volumes can be safely transacted we need lots of Darknodes which means we need lots of fees. In this initial phase, the volume will be lower and so fees need to be higher to sustain Darknode numbers. As volume grows, the fee can be reduced without resulting in the loss of Darknodes.

 

Q: Can a centralized dark pool using the matching engine then get away with paying pennies in fees for block trades?

A: It will pay for the work it consumes. The challenge is that allowing general-purpose scripting means that “forcing” dark pools to pay per volume at the order matching level is impossible. They could just defer to the general purpose scripting level and write the same functionality there.

If settlement was being done on RenVM, as oppose to order matching (or in addition to it), then the interoperable liquidity features of RenVM are being engaged which requires special instructions that cannot be built using general purpose scripting (in theory you could build them but they are so wildly inefficient that it’s not reasonable to use general purpose scripting in this way).

As it stands, the only known way to do private interoperable trades in a way that is decentralized, trustless, and unable to be canceled by either party (the precise needs of a decentralized dark pool but also a wide range of other financial applications) is to use something like secure multiparty computation and RenVM is the only solution that is efficient enough at curve cryptography to actually make this usable in practice.

 

Q: What would be the recommended fee model for a dark pool with non-monetary assets? For example, consider an exchange between two token identifiers representing shares in a prediction market.

A: Whatever the computations/data required to do that exchange are would dictate the minimum fee. Increasing that can be used to prioritize the work over other work.

 

Q: Requiring an upfront fee for limit orders isn't great UX. At the dark pool layer, why not return the fee for canceled orders? Is that different from a trader spamming the network with unrealistic orders using a dynamic fee?

A: This would allow people to attack the virtual machine by getting it do work that it isn’t being paid for. When using dynamic fees, the fee is an intrinsic part of the computation. With Dai fees, one has to come before the other and doing the compute first would allow an attack scenario where you request a heavy computation and then don’t pay for it.

 

Q: Hence my last question: how does that scenario differ from a trader spamming/pinging the network with orders that will never be filled in a dark pool using dynamic fees?

A: Because dynamic fees are only available for the movement of tokens. Order matching (the stage that comes before settlement and thus movement of tokens) is not in itself the movement of tokens and so requires Dai fees.

 

Q: Say for an unfillable limit order, is it in the realm of cents? Fractions of a cent?

A: That’s about what I’d expect. Just under 1c depending on the number of orders on the book (and we will continue to push that lower as we reduce the hardware requirements of Darknodes). Still 50-100x improvement over Ethereum in regards to cost and speed

 

Q: Then can a trader could just spam the venue?

A: The venue can implement its own spam protection. RenVM itself is permissionless so it can only use economic incentives to protect itself. Applications can apply their kinds of context-specific restrictions (KYC is an example of such a restriction, albeit not one around spamming)

 

Q: You say here that everyone should see more frequent smaller payments, but in the blog, it says payments will be once per month. Which one is correct?

A: Both are correct. Fees will be allocated to Darknodes more frequently (and this will be reflected in the DCC) but Darknodes will only be able to claim these fees at the end of each payment cycle.

 

Q: For example, theoretically if 4 weeks cycle starts 15th may all darknode which were registered will earn fees but if somebody registers a node 16th may his node will be off and he will be waiting half a month to earn fees, correct?

A: If you are not already registered and whitelisted before a cycle begins you will not earn fees in that cycle. The optimal behavior is register and whitelist on the last day of a cycle.

 

Q: What date new cycle will start?

A: Cycles are currently set to be 7 days in length so that Darknodes that are already registered are able to get whitelisted quickly. Soon we will move to 4 week period but certainly, let the community know when we make that switch via a formal announcement.

 

Q: If I deregister my Darknode with Pending Fees in my DCC will I lose them?

A: Yes, The safest thing to assume: if you haven’t withdrawn the fees when you deregister then you will not get those fees if you deregister. It says “Claim again in 11 hours”. At the moment, the cycles are set to only one day, to ensure time for all Darknodes to correctly adjust to the new contract. But, a cycle will usually be 4 weeks. See the messages above about why.

 

Q: Do we have to manually claim pending fees to move them to withdrawable?

A: You can manually claim fees to move them to withdrawable. But your Darknode will do it automatically for you (assuming it has enough gas)

 

Q: Are the cycles ‘prorated’ so to speak? As I understand, a node needs to be active for the entire cycle in order to receive rewards? Does that mean if I deactivate a node after a cycle begins to downgrade my vps I am ineligible for rewards from that entire cycle?

A: Yes, this is done for three reasons.

The first is that you get a better $ per month overall by only having to claim your fees once per month (claiming requires gas, therefore costs a bit of money, a couple cents per month is okay but every day or even every payment is looking worse).

The second is that it enables a more even distribution of the fees over the course of the whole month.

The third, and the most important is that it forces stability. The security and liveliness of the network depend on people keeping their Darknodes running (this is just as important as having people running nodes). Having to wait a month is an economic incentive to maintain the Darknode for the whole month. Your hardware expenses are billed once a month and salaries are typically quoted once per month so this is the reason for the particular choice of four weeks (whole weeks are nice and it’s just under the one month cadence).

If you fail to maintain the Darknode sufficiently during a cycle the Darknode will not earn fees ever again (you will need to deregister and register a new one). In the latest version of the Darknode CLI there is now a command that will resize the hardware for you without causing much downtime (or needing to deregister and reregister).

 

Q: Are you still planning to Release 3rd Party tool for Darkpools in Q2? 

A: We are aiming to put out dev tools but not for third-party dark pools. We will be releasing them for third-parties to use the interoperable features of RenVM as this is the more general feature. Simply said, cross-chain interop needs to come first, otherwise dark pools won’t be that useful.

 

Q: Wrt decentralized dark pools, I think you mentioned that RenEx is no longer being pursued as a formal product.
1) I know it's a "demo," but is it being deprecated? What should we expect from it going forward?

2) There are no other decentralized dark pools yet. Are you expecting most dark pool volume to come from new, upstart dark pools not built yet or existing dex's planning to add dark pool functionality?

A: As RenVM progresses and the interop layer makes its way to Mainnet, RenEx will be upgraded to make use of these new features (and by extension pay these new fees). We expect volume to come from some new applications being built by other teams and from integration into existing DEXs / DeFi.

 

Q: You seemed to insinuate yesterday that a prediction market dark pool should use the Dai fee model rather than the dynamic fee model.

Assume an Augur market with YES and NO shares, where shares are represented by ERC777 tokens. They don't have an explicit monetary value outside of the Augur contracts. If a trade is made with these shares, then rather than Darknode operators manually having to cash in these shares for Dai on Augur, could there not be a RenVM<>Augur swapper that swapped the shares for Dai? Thereby making the dynamic fee possible for these assets? Darknode operators may be left with an assortment of YES and NO shares from various markets that are worthless unless they're redeemed for Dai in Augur. My question is: other than a  RenVM<>Augur swapper, what would prevent a dark pool from using the dynamic fee model?

A: The settlement layer for RenVM only really comes into play for cross-chain settlements. In the case of Augur <> Dai this would just settle on-chain, unless you had explicitly built a script into RenVM to manage this secretly. In this case the movement of the fungible token would require dynamic fees but the movement of the NFT wouldn’t.

The biggest challenge is finding a way to express these fees in a way that is generalizable. We don’t want to embed a whole bunch of specific cases into the protocol. All these scenarios are subtly different and it is better to have one or two rules that captures most use cases optimally and some use cases sub-optimally than to have an indeterminate number of rules (every time someone builds an application we would be asking ourselves “how do we modify the fee rules to accommodate this?”)

I could imagine a way whereby Ren requires Dai fees to be dynamic by “estimating” the equivalent price of NFTs moves (i.e. transferring an NFT of equivalent value of $X would require X*0.001 Dai). But even this is specific to the use case of NFTs.

 

Q: will you be able to run a Lightnode client side, in the browser?

A: Not in the browser. The intent is that Lightnodes will be what the browser interacts with. The nature of SSL prevents Darknodes being able to be accessed directly by browsers (most block https => http content) because Darknode do not have their own domains and therefore cannot have SSL certs (and even if they could this requires a centralized authority to provide it). Lightnodes alleviate this by allowing developers to deploy them behind their application domain so that the browser can communicate with it over SSL, and then it can communicate with the Darknodes.

 

Лично я, прочитав этот FAQ, решил, что докуплю ещё одну Тёмную ноду в ближайшем будущем.

Если так пойдет (я о том, что показывает цена последние две недели), то стоимость ноды перевалит за +$5к.
Еще интересно, что Loong в открытую говорит (но только когда его спрашивают) о недостатках других реализаций sMPC, мне кажется странным, что эта информация ни кем из крипто-СМИ не растиражирована. 
 

Поделиться сообщением


Ссылка на сообщение
5 часов назад, antaeus сказал:

Если так пойдет (я о том, что показывает цена последние две недели), то стоимость ноды перевалит за +$5к.
Еще интересно, что Loong в открытую говорит (но только когда его спрашивают) о недостатках других реализаций sMPC, мне кажется странным, что эта информация ни кем из крипто-СМИ не растиражирована. 

Они красавцы и в работе, и в том, что не обсирают чужие проекты, а говорят об этом только когда спрашивают.

Просто у них нет маркетингового отдела, поэтому по всем сми и не разлетаются слова Loong. Ещё одно доказательство того, как работают крипто-СМИ.

Поделиться сообщением


Ссылка на сообщение
46 минут назад, cp287 сказал:

Они красавцы и в работе, и в том, что не обсирают чужие проекты, а говорят об этом только когда спрашивают.

Просто у них нет маркетингового отдела, поэтому по всем сми и не разлетаются слова Loong. Ещё одно доказательство того, как работают крипто-СМИ.

Да, у них очень профессиональный стиль работы: говорить после того как это сделано и делать укладываясь в сроки. Понятно, что цели меняются по ходу реализации дорожной карты и сама дорожная карта может меняться, но все ключевые вещи - укладываются в сроки. О других проектах отзываются максимально корректно.
Я большой фанат REN, думаю ничего если выложу отчет Delphi Digital с исследованием о проекте.

Кстати, REN был одним из первых проектов на который они выпустили отдельный отчет.

February 28th, 2019 - Ren.pdf

Изменено пользователем antaeus

Поделиться сообщением


Ссылка на сообщение

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.


×
×
  • Создать...